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(54) INTEGRATED RNANCE RISK MANAGER AND FINANCIAL TRANSACTION MODELING 
DEVICE 

(57) A class corresponding to a plurality of transac- 
tion entities are collectively processed to realize a vir- 
tual transaction. A cash flow type transaction entity is 
managed as a set of cash flow elements (CashFlowLet) 
for each unit transaction period on each of the receipt 
side and the payment side, and a current price evaluat- 
ing operation for each element is commonly operated. 
An option transaction is realized by a class storing a 
class of an original asset transaction as a container. A 
financial curve definition function and a function of real- 
izing a virtual curve by combining a plurality of financial 
curves are implemented. A user interlace capable of 
easily changing a parameter for use in risk manage- 
ment and displaying a simulation result thereof can be 
provided. 
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Description 

Background of the Invention 
Field of the Invention 

[0001] The present invention relates to a financial 
risk management technology for totally managing the 
risk in financial transactions using computers, and more 
specifically to a financial risk management apparatus 
capable of freely designing desired financial goods by 
arbitrarily setting and combining parameters relating to 
actual or imaginary financial transactions, and quickly 
performing a simulation of imaginary financial transac- 
tions or an operation of actual financial goods (risk man- 
agement), and to a financial transactions modeling 
apparatus applicable to the financial risk management 
apparatus. 

Description of the Related Art 

[0002] With the diversification of the financial mar- 
ket the financial transactions also have become diversi- 
fied and complicated, and the risk management of the 
financial transactions is required by persons engaged in 
financial facilities and their customers. 
[0003] Especially required is the general risk man- 
agement technology for compound transactions includ- 
ing a plurality of financial transaction entities such as 
cancelable swaps, swaps with a cap, etc. 
[0004] To successfully manage the risk in each 
transaction entity which is the base of the above 
described compound transactions, there have conven- 
tionally been the necessity of programming a risk man- 
agement module depending on the type of each 
transaction entity. With an increasing amount of devel- 
opment costs, the conventional technology has the 
problem that new financial transactions cannot be easily 
or quickly managed. 

[0005] There are some typical conventional risk 
management systems provided with every function 
implementation. However, since these systems need to 
implement all functions of financial transactions such as 
foreign exchange spots, cash equities, discount bonds, 
interest rate swaps, coupon swaps, currency swaps, 
options, etc., a large amount of development cost is 
required, thereby exceedingly raising the sales cost 
involved. 

[000S] The transactions of a cash flow type based 
on 'exchange' are in the majority of the actual financial 
transactions. However, the conventional systems do not 
utilize such common features and therefore are not effi- 
cient systems as a whole. As a result, they are subject 
to a raise in the cost as described above. 
[0007] On the other hand, there has been the con- 
ventional technology referred to as tying with strings as 
the general risk management technology for compound 
transactions. 



[0008] In this conventional technology, a common 
linked code is assigned to a plurality of transaction enti- 
ties, and the linked code is used in a database to collec- 
tively manage the risk in a plurality of transaction 

5 entities as compound transactions. 

[0009] In the above described conventional technol- 
ogy, to perform all operations required to manage the 
risk in compound transactions, each of the transaction 
entities forming part of the compound transactions is 

10 retrieved from a database using a linked code, a risk 
management operation is performed on each of the 
retrieved transaction entities, each operation result is 
stored in the database, and retrieving and aggregating 
procedures are necessary in the database based on the 

is association between the transaction entities realized by 
any method. 

[0010] Therefore, there has been the problem with 
the conventional technology that a large scale program- 
ming is required to develop a general risk management 
20 system for compound transactions, thereby incurring a 
raise in a development cost and an undesired large 
scale system. 

[0011] In addition, a large volume of arithmetic 
operations are performed by a developed general risk 
25 management system, and the performance of the gen- 
eral risk management apparatus can hardly be 
improved. 

[0012] Furthermore, there has been the problem 
that with an increasing number of types and an increas- 
30 ing number of transaction entities forming financial 
transactions, a larger storage capacity is required to 
store the data. 

[001 3] To solve the above described problem, it has 
been necessary for the conventional technology to pro- 
as vide a large-capacity and high-performance computer in 
financial facilities, etc. which process a large volume of 
financial transactions, and the equipment funds and 
working cost for the general risk management has 
soared high. 

40 [0014] The present invention has been developed 
to solve the above described problems, and aims at 
reducing the development and working cost for the gen- 
eral risk management system for financial transactions 
to improve the system performance. 

45 

Summary of the Invention 

[0015] First, such words as 'class', Instance', 
'method', 'container class', etc. in the specification and 

so the attached drawings indicate predetermined functions 
and configurations in the well-known object-oriented 
concept In addition, words other than the above listed 
words may also indicate predetermined functions in the 
object oriented concept Furthermore, 'refer* indicates to 

55 read necessary data according to data storage address 
information directly stored in a refened-from program. 
[0016] FIG. 1 is a block diagram showing the princi- 
ple of the first aspect of the present invention. 
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[0017] The first aspect of the present invention is 
based on the general financial risk management appa- 
ratus for managing a risk in compound transactions 
(which may include only one transaction time point) 
including one or more transaction entities (swap trans- 
actions, option transactions, etc.) relating to financial 
goods. 

[001 8] Each of one or more transaction entity mod- 
eling units 103 includes a storage unit 102 for individu- 
ally storing information about each transaction entity, 
and a current price evaluating operations unit 101 about 
transaction entities. For example, the transaction entity 
modeling unit 103 is a module (a class module 501, an 
RDBMS module 502, and an RDB module 503) for hold- 
ing in the storage unit 1 02 a parameter for use in mode- 
ling a transaction entity as a class member, holding the 
current price evaluating operations unit 101 as a 
method (GetNPV method), and operating an instance 
(TContract instance) at a predetermined class in an 
object-oriented concept. 

[0019] A virtual transaction unit 107 includes a ref- 
erence information storage unit 105 containing a refer- 
ence information group 104 for use in referring to each 
of the transaction entity modeling units 103; and a com- 
pound transactions characteristic computation unit 106 
for sequentially referring to each of the transaction entity 
modeling units 103 from the reference information 
group 104 according to a predetermined instruction, 
obtaining operation results from the current price evalu- 
ating operations unit 101 , and computing the character- 
istics of the compound transactions based on each of 
the operation results. The above described transaction 
entity modeling unit 103 is mounted as a list structure, 
and the virtual transaction unit 107 is a module (the 
class module 501, the RDBMS module 502, and the 
RDB module 503) for holding through the reference 
information storage unit 105 the reference information 
group 104 as a list member (link list LinkList), holding 
the compound transactions characteristic computation 
unit 106 as a virtual method (GetNPV)* and operating 
an instance (TVirtual Contract instance) of a predeter- 
mined container class in the object oriented concept. 
[0020] A financial characteristic computation unit 
108 is descrtoed later. 

[0021] With the configuration of the first embodi- 
ment of the present invention, the three requests to sim- 
plify the entire system, speed up risk management 
operations, and compress data, which have convention- 
ally been hardly attained simultaneously, can be suc- 
cessfully attained simultaneously in managing the risk 
in compound transactions (compound goods) relating to 
financial goods containing one or more transaction enti- 
ties. 

[0022] That is, with the configuration according to 
the first aspect of the present invention, all transactions 
can be collectively processed by one virtual transaction 
unit 107 regardless of the type of a transaction to be 
managed, or regardless of whether a single or a plural- 



ity of components are contained in the transaction. 
Therefore, an application programmer can write compu- 
ter programs without considering the type of transaction 
or the configuration. 

5 [0023] Practically, all transactions can be constantly 
recognized as, for example, a TVirtual Contract 
instance, etc. by realizing the transaction entity mode- 
ling unit 103 as an instance of a TContract class, and 
the virtual transaction unit 107 as a TVirtual Contract 

10 class. 

[0024] Then, an application programmer can easily 
develop various functions of managing risks only by 
individually develop methods for TVirtual Contract 
instance, etc. for realizing the compound transactions 
is characteristic computation unit 106 in the virtual trans- 
action unit 107 without changing the structure of the 
TContract class, etc. 

[0025] In addition, with the configuration according 
to the first aspect of the present invention, the current 

20 price evaluating operations unit 101 in the transaction 
entity modeling unit 103 can independently perform a 
current price evaluation operation through the reference 
information group 104, and the compound transactions 
characteristic compulation unit 106 in the virtual trans- 

25 action unit 107 can finally summarize the current price 
evaluating operations only by one of more transaction 
entity modeling units 103 having a simple structure 
referred to by the reference information group 104 such 
as a link list etc. in the virtual transaction unit 107, and 

30 issuing an instruction to the virtual transaction unit 1 07. 
As a result, various operations performed in the risk 
management can be quickly performed by performing 
sequential accessing operations to each of the transac- 
tion entity modeling units 103 through the reference 

35 information group 1 04. 

[0026] Practically, the transaction entity modeling 
unit 103 is realized as an instance of the TContract 
class to be held with the current price evaluating opera- 
tions unit 101 as a GetNPV method, and the virtual 

40 transaction unit 107 is realized as an instance of the 
TVirtualContract container class with the reference 
information group 104 held as a link list and the com- 
pound transactions characteristic computation unit 106 
held as a virtual method GetNPV. Thus, a high-sped risk 

45 management operation can be easily performed on 
memory. 

[0027] Furthermore, with the configuration accord- 
ing to the first aspect of the present invention, since the 
virtual transaction unit 107 refers to one or more irtde- 

so pendent transaction entity modeling units 103, each of 
the transaction entity modeling units 103 respectively 
for swap transactions, option transactions, etc. can be 
referred to by a plurality of virtual transaction units 107. 
That is, the data of one transaction entity modeling unit 

55 103 can be utilized by a plurality of financial transac- 
tions. As a result, in financial facilities, etc. which proc- 
ess a large volume of financial transactions, a large data 
compression effect can be obtained, thereby reducing 
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the necessary amount of computer resources. 
[0028] In this case, for example, a subtle difference 
in financial characteristics to each transaction entity 
modeling unit 103 can be absorbed for each of the 
financial transactions by assigning to the compound s 
transactions characteristic computation unit 106 in the 
virtual transaction unit 107 the function of computing a 
new operation result by multiplying each operation 
result by a predetermined transform coefficient 
[0029] FIG. 2 shows the configuration of the second 
aspect of the present invention. 
[0030] The second aspect of the present invention 
is based on the financial transactions modeling appara- 
tus for modeling a transaction (cash flow type transac- 
tion) established by processing financial transactions 
(including financial goods other than currencies) in a 
predetermined transaction period 201 . The configura- 
tion according to the second aspect of the present 
invention is not based on the configuration according to 
the first aspect of the present invention, but is a config- 
uration realizing the transaction entity modeling unit 103 
with the configuration according to the first aspect of the 
present invention. 

[0031 ] Each of one or more unit transaction mode- 
ling units 207 includes a unit transaction information 
storage unit 206, provided for each of one or more unit 
transaction periods (CashFlowLet) 204 obtained by 
dividing a predetermined transaction period 201 for 
each receipt or payment in each of a receiver (receipt 
side) 202 and a payer (payment side) 203 relating to a 
financial transaction, for individually storing information 
about unit transactions, and a current price evaluating 
operation unit 205 for the unit transaction period 204. 
The unit transaction modeling unit 207 is a module (the 
class module 501, the RDBMS module 502, and RDB 
module 503) for holding, for example, as a class mem- 
ber a parameter for use in performing a current price 
evaluating operation for the unit transaction period 204 
in the unit transaction information storage unit 206, 
holding the current price evaluating operation unit 205 
(GetNPV) as a method, and operating an instance in a 
predetermined class (TCFSwap instance) in the object- 
oriented concept. The above described current price 
evaluating operation unit 205 performs, for example, a 
current price evaluating operation performed based on 
a future value index computed using one of the three 
types of indices of interest earning rate, and price, and 
an evaluation value independent of any of the interest, 
earning rate, and price in the unit transaction period 204 
corresponding to the unit transaction modeling unit 207. 
Furthermore, the current price evaluating operation unit 
205 includes, for example, a discount rate multiplication 
unit for obtaining a current value as a current price eval- 
uating operation result by multiplying the above 
described current price evaluating operation result by a 
predetermined discount rata 
[0032] A transaction sequence modeling unit 21 1 
includes a reference information storage unit 209 con- 



taining a reference information group 208 for referring to 
the unit transaction modeling unit 207 corresponding to 
each of the receiver 202 and the payer 203 relating to a 
financial transaction; and a transaction sequence char- 
acteristic computation unit 210 for sequentially referring 
to each of the unit transaction modeling units 207 from 
the reference information group 208 in each of the 
receiver 202 and the payer 203 relating to the financial 
transaction at a predetermined instruction, obtaining 
operation results from the current price evaluating oper- 
ation unit 205, and computing the characteristic of a 
transaction sequence based on each of the operation 
results. The unit transaction modeling unit 207 is 
mounted as a list structure. The transaction sequence 
modeling unit 211 is a module (the class module 501, 
the RDBMS module 502, and the RDB module 503) for 
holding, for example, the reference information group 
208 in each of the receiver 202 and the payer 203 relat- 
ing to the financial transaction as a list member (Rec- 
Cash Flows, PayCash Flows), the transaction sequence 
characteristic computation unit 210 as a virtual method 
(GetNPV). and operating an instance (TCSwap 
instance) in a predetermined container class in the 
object-oriented concept 

[0033] A financial characteristic computation unit 
213 is described later. 

[0034] With the above descrtoed configuration 
according to the second aspect of the present invention, 
various financial transactions based on 'exchange' such 
as foreign exchange, lending/borrowing, bonds, shares, 
commodities, interest rate/currency swaps, equity 
swaps, commodity swaps, etc. can be integrated and 
modeled by a transaction sequence modeling unit 21 1 . 
To be more concrete, cash flow type transaction entities 
are collectively managed as a set of cash flow elements 
(CashFlowLet) for each unit transaction period 204 in 
each of the receiver 202 and the payer 203. Each ele- 
ment is collected by the transaction sequence modeling 
unit 21 1 for referring to the elements. With the diversifi- 
cation of reference types, various 'exchange-based 
cash flow type transactions can be collectively modeled. 
[0035] As a result, the system configuration of the 
financial transactions modeling apparatus can be com- 
pact, thereby considerably reducing development and 
sales costs. 

[0036] It is not necessary that the payment for 
financial transactions should be made by currency. It 
can also be made by bonds, shares, commodities, etc. 
In this case, the current price evaluating operation unit 
205 in the unit transaction modeling unit 207 can com- 
pute a future value index by performing a current price 
ratio operation in accordance with an interest an earn- 
ing rate, or a price in the payment unit of financial trans- 
actions (for example, the number shares) in the 
corresponding unit transaction period 204. That is, 
according to the second aspect of the present invention, 
the exchange-based cash flow type transactions can be 
collectively processed for any unit of financial transac- 
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tion object 

[0037] With the configuration according to the sec- 
ond aspect of the present invention, a user interlace unit 
212 (TCFChaiaBuiWCF method) can be further 
included. The user interface unit 212 is designed to s 
compute one or more unit transaction periods 204 by 
dividing a predetermined transaction period 201 for 
each receiver or payer based on the settings of date 
information by the user, etc., generate the unit transac- 
tion modeling unit 207 for each of the computed unit 10 
transaction periods 204 in each of the receiver 202 and 
the payer 203 of a financial transaction object and gen- 
erate the reference information group 208 in the trans- 
action sequence modeling unit 211 corresponding to 
each of the receiver 202 and the payer 203. is 
[0038] With the configuration, the user can process 
various financial transactions based on the 'exchanging* 
as described above through a general user interface, 
thereby conspicuously improving the operabilrty. 
[0039] Furthermore, with the configuration accord- 20 
ing to the second aspect of the present invention, the 
user interface unit 212 (magic sheet) can further be 
included. For each unit transaction modeling unit 207, 
the user interface unit 212 amends a parameter for use 
in financial transactions modeled by the unit transaction 25 
modeling unit 207, and issues a predetermined instruc- 
tion depending on the amendment 
[0040] With the above described configuration, the 
user can customize in detail the exchange-based cash 
flow type transactions. 30 
[0041 ] FIG. 3 is a block diagram showing the princi- 
ple of the third aspect of the present invention. 
[0042] The third aspect of the present invention is 
based on the financial transactions modeling apparatus 
for modeling option transactions relating to financial 35 
goods. The configuration according to the third aspect 
of the present invention is not based on the configura- 
tion according to the first aspect of the present inven- 
tion, but realizes the transaction entity modeling unit 
103 with the configuration according to the first aspect 40 
of the present invention. 

[0043] An original asset modeling unit 303 includes 
a storage unit 302 for individually storing information 
about original assets of option transactions, and a cur- 
rent price evaluating operation unit 301 for the original 45 
assets. The original asset modeling unit 303 is a module 
(the class module 501, the RDBMS module 502, and 
the RDB module 503) for holding, for example, a param- 
eter for user in modeling the original assets as a class 
member in the storage unit 302, holding the current so 
price evaluating operation unit 301 as a method (Get- 
NPV), and operating a predetermined instance (TOp- 
tion instance) in the object-oriented concept 
[0044] An option modeling unit 308 includes a refer- 
ence information storage unit 305 for containing refer- 55 
ence information group 304 for reference to each of the 
original asset modeling units 303; and an option trans- 
action characteristic computation unit 307 for computing 



the characteristic of option transactions based on each 
operation result obtained by the current price evaluating 
operation unit 301 in the original asset modeling unit 

303 sequentially referred to by the reference information 
group 304 and/or a predetermined evaluation model (a 
black sholes model, etc.) 308. The original asset mode- 
ling unit 303 is mounted as, for example, a list structure. 
The option modeling unit 308 is a module (the class 
module 501, the RDBMS module 502, and the RDB 
module 503) for holding the reference information group 

304 as a list member (Undertyings), holding the option 
transaction characteristic computation unit 307 as a vir- 
tual method (GetNPV, etc.), and operating an instance 
(TOption instance) of a predetermined container class 
in the object-oriented concept. For example, when a 
predetermined instruction is issued, the option mode- 
ling unit 308 sequentially refers to the original asset 
modeling unit 303 from the reference information group 
304, obtains an operation result from the current price 
evaluating operation unit 301, and computes the char- 
acteristic of the option transaction based on each oper- 
ation result and a predetermined evaluation model 306 
when the date set for an option transaction refers to the 
in the money state of the option transaction, and com- 
putes the characteristic of the option transaction based 
on only the predetermined evaluation model 306. 
[0045] The financial characteristic computation unit 
213 is described later. 

[0046] In the conventional option model definition, 
the characteristic of original assets is added to the eval- 
uation model of the option itself to determine the model 
of the option. On the other hand, according to the third 
aspect of the present invention, the original asset mod- 
eling unit 303 can be designed and realized completely 
separately and independently from the evaluation 
model of an option, and the option modeling unit 308, 
which is the body of the option, can refer to any number 
of original asset modeling units 303 independently real- 
ized as described above through the reference informa- 
tion group 304. That is, only by issuing one instruction to 
the option modeling unit 308, the current price evaluat- 
ing operation unit 301 in the original asset modeling unit 
303 independently performs a current price evaluating 
operation through the reference information group 304, 
and finally the option transaction characteristic compu- 
tation unit 307 in the option modeling unit 308 can com- 
pute the characteristic of option transactions based on 
each operation result, a predetermined evaluation 
model (in the money state) or only a predetermined 
evaluation model (out of the money). As a result, with 
the configuration according to the third aspect of the 
present invention, the system design of option transac- 
tions can be simplified, thereby improving the perform- 
ance and reducing development and sales costs. 
[0047] Furthermore, with the configuration accord- 
ing to the third aspect of the present invention, data of 
one original asset modeling unit 303 can be shared for 
a plurality of option transactions. As a result, in such 
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banking facilities as process a large volume of similar 
option transactions, a large data compression effect can 
be obtained, thereby reducing a necessary amount of 
computer resources. 

[0048] In addition, with the configuration according 
to the third embodiment of the present invention, the 
option modeling unit 308 computes the characteristic of 
an option transaction based on each of the operation 
results from the current price evaluating operation unit 
301 in each of the original asset modeling units 303 and 
on a predetermined evaluation model 308 when the 
date set for the option transaction indicates the in-the- 
money state of the option transaction. When the date 
indicates the out-of-the-money state for the option 
transaction, the option modeling unit 308 computes the 
characteristic of the option transaction based on only 
the predetermined evaluation model 306. As a resuft the 
switching between in-the-money state and the out-of- 
the-money state can be simply controlled, and a high- 
performance system can be successfully realized. 
[0049] The fourth aspect of the present invention is 
based on the above described first, second or third 
aspect of the present invention. 
[0050] The financial characteristic computation unit 
108, 213, or 309 shown in FIGS. 1 , 2, or 3 computes the 
financial characteristic (containing real time data) at 
each of the current price evaluating operations per- 
formed by each of the current price evaluating opera- 
tions units for each of the current price evaluating 
operations units 101, 205, or 301, and provides the 
obtained financial characteristic for each current price 
evaluating operations unit 101, 205, or 301. The finan- 
cial characteristic computation unit 108, 213, or 309 is a 
module (the class module 501, the RDBMS module 
502, or RDB module 503) for modeling, for example, the 
above described financial characteristic, and operating 
an instance (TCntYieldCurves, TCntPriceCurves, 
TCntVolsCurves, etc.) in a predetermined class in the 
object-oriented concept. The current price evaluating 
operations unit 101, 205, or 301 contains reference 
information (DiscCurve, PriceCurve, etc.) stored by the 
above described instance in a predetermined class in 
reference to a predetermined method for computing the 
above descrfoed financial characteristic. 
[0051] A financial characteristic definition unit for 
defining the above described financial characteristic 
can be further included in the configuration according to 
the fourth aspect of the present invention. 
[0052] With the above described fourth aspect of 
the present invention, the user can freely design and 
introduce each of the financial characteristics such as a 
unit of financial transactions, a holiday exclusion city, an 
yield curve, a price curve, a volatility curve, etc. to a cur- 
rent price evaluating operation. 
[0053] With the configuration according to the 
fourth aspect of the present invention, the financial 
characteristic computation unit 108, 213, or 309 can be 
designed to comprise a plurality of single financial char- 



acteristic computation units for computing each of a plu- 
rality of single financial characteristics obtained when 
each current price evaluating operation is performed by 
each of the current price evaluating operations units 

5 101, 205, and 301 ; and a virtual financial characteristic 
computation unit for computing a new virtual financial 
characteristic by composing the above described plural- 
ity of single financial characteristics, and providing the 
virtual financial characteristics for each of the current 

w price evaluating operations unit 101, 205, and 301. In 
this case, each single financial characteristic computa- 
tion unit is a module (the class module 501 , the RDBMS 
module 502, and the RDB module 503) for operating 
each instance (TAbsCurve) in each of a plurality of pre- 

is determined classes in the object-oriented concept. The 
virtual financial characteristic computation unit is, for 
example, a module for operating an instance (TCnt Vir- 
tual Curve) in a predetermined super class inherited by 
a plurality of predetermined classes. The current price 

20 evaluating operations unit 101 . 205, or 301 contains ref- 
erence information stored in the super class in refer- 
ence to a predetermined method for computing a virtual 
financial characteristic. 

[0054] With the configuration, the user can com- 
as pose a more effective financial characteristic from a plu- 
rality of financial characteristics, and introduce it to a 
current price evaluating operation. 
[0055] Furthermore, the present invention can be 
designed as a computer-readable storage medium 
30 used to direct a computer to perform functions similar to 
those realized by the above described aspects of the 
present invention. 

Brief Description of the Drawings 

35 

[0056] 

FIG. 1 is a block diagram (1) showing the present 
invention; 

40 FIG. 2 is a block diagram (2) showing the present 
invention; 

FIG. 3 is a block diagram (3) showing the present 
invention; 

FIG. 4 shows the concept of the present invention; 
45 FIG. 5 shows the entire configuration according to 
an embodiment of the present invention; 
FIG. 6 shows the virtual transaction management 
for cancelable swaps; 

FIG. 7 shows the virtual transaction management 
so for plain vanilla swaps; 

FIG. 8 shows the structure of a class for realizing a 

virtual transaction; 

FIG. 9 shows data compression (1); 

FIG. 10 shows data compression (2); 
55 FIG. 11 shows the structure of realizing a virtual 

transaction on the RDBMS; 

FIG. 1 2 shows the configuration (1) of a table on the 

RDB; 



6 



11 



EP1 017004 A1 



12 



FIG. 13 shows the TCFSwap instance image and 
the structure of data in the TCF class; 
FIG. 14 shows the outline of the attributes in the 
TCFChain class; 

FIG. 15 shows the configuration (2) of a table on the 
RDB; 

FIG. 16 shows the outline of the attributes in the 
TCF class; 

FIG. 1 7 shows the configuration (3) of a table on the 
RDB; 

FIG. 18 shows the procedure of generating a TCF- 
Swap instance; 

FIG. 19 is a flowchart of the process of the 
TCFChain.BuildCF method; 
FIG. 20 is a flowchart of the process of the 
TCF. Update method; 

FIG. 21 is a chart showing the classification of 
transactions; 

FIG. 22 shows the data structure and an instance 
image of the TOption; 

FIG. 23 is a chart showing the outline of the 
attributes and methods of the TOption; 
FIG. 24 shows the data structure of the TPwr- 
Gadget class; 

FIG. 25 shows an example of a screen of the main 
control panel; 

FIG. 26 show an example of an initial screen on 
which a cash flow transaction is processed; 
FIG. 27 shows an example (1) of a screen on which 
an interest rate swap transaction is processed; 
FIG. 28 shows an example (2) of a screen on which 
an interest rate swap transaction is processed; 
FIG. 29 shows an example (3) of a screen on which 
an interest rate swap transaction is processed; 
FIG. 30 shows an example (4) of a screen on which 
an interest rate swap transaction is processed; 
FIG. 31 shows an example (5) of a screen on which 
an interest rate swap transaction is processed; 
FIG. 32 shows an example (6) of a screen on which 
an interest rate swap transaction is processed; 
FIG. 33 shows an example (7) of a screen on which 
an interest rate swap transaction is processed; 
FIG. 34 shows an example (8) of a screen on which 
an interest rate swap transaction is processed; 
FIG. 35 shows an example (9) of a screen on which 
an interest rate swap transaction is processed; 
FIG. 36 shows an example (1) of a screen on which 
an equity swap transaction is processed; 
FIG. 37 shows an example (2) of a screen on which 
an equity swap transaction is processed; 
FIG. 38 shows an example (1) of a screen on which 
an foreign exchange transaction is processed; 
FIG. 39 shows an example (2) of a screen on which 
an foreign exchange transaction is processed; 
FIG. 40 shows an example (3) of a screen on which 
an foreign exchange transaction is processed; 
FIG. 41 shows an example of an initial screen for 
the PwrGadget function; 



FIG. 42 shows an example of a definition screen for 
a holiday exclusion city; 

FIG. 43 shows an example of a definition screen for 
a transaction unit; 
5 FIG. 44 shows an example (1) of a definition screen 
for an yield curve; 

FIG. 45 shows an example (2) of a definition screen 
for an yield curve; 

FIG. 46 shows an example (1) of a definition screen 
w for a price curve; 

FIG. 47 shows an example (2) of a definition screen 
for a price curve; 

FIG. 48 shows an example of a definition screen for 
a virtual curve; 

is FIG. 49 shows an example of a screen on which a 

swap transaction, which is an original asset in an 

option transaction, is processed; 

FIG. 50 shows an example of a definition window 

for an option transaction; 
20 FIG. 51 shows an example (1) of a screen on which 

an option transaction is processed; 

FIG. 52 shows an example (2) of a screen on which 

an option transaction is processed; 

FIG. 53 shows an example (1) of a screen for a 
25 financial transaction composing procedure; 

FIG. 54 shows an example (2) of a screen for a 

financial transaction composing procedure; 

FIG. 55 shows an example (3) of a screen for a 

financial transaction composing procedure; 
30 FIG. 56 shows an example (4) of a screen for a 

financial transaction composing procedure; and 

FIG. 57 shows an example of an initial screen (for 

emphasis). 

35 Description of the Preferred Embodiments 

[0057] The preferred embodiments of the present 
invention are described below by referring to the 
attached drawings. 

40 [0058] FIG. 4 shows the concept of an embodiment 
of the present invention. FIG. 5 shows the entire config- 
uration of an embodiment of the present invention. The 
concept and the details of the embodiment of the 
present invention are sequentially described below by 

45 referring to the drawings. 

0. Features of the present invention 

[0059] The number of features of the present inven- 
so tion is 6 as follows. 

1 . Frame of the TVirtual Contract container class for 
realizing a virtual transaction composed of classes 
(TCFSwap/TOption classes) corresponding to a 

55 plurality of transaction entities (virtual transaction 
management system) 

2. Frame of the TCFSwap container class for man- 
aging cash flow type transaction entities as a set of 



7 



13 



EP 1 017004 A1 



14 



cash flew elements (CashFlowLet) for each unit 
transaction period in each of the receipt side and 
the payment side, and realizing a cash flow type 
transaction entities composed of the TCF classes 
corresponding to each CashFlowLet 

3. Current price evaluating operation process 
shared among the TCF classes (CashFlowLet) 

4. Frame of each "TOption (container) class 

5. Financial curve defining function 

6. User interface for easily changing a parameter 
for risk management and displaying a simulation 
result of the change 

[OOSO] Each of the above described features 1 
through 6 of the present invention are described below 
in detail by referring to each of the embodiments. 

1 . TVirtualContract container class for realizing virtual 
transactions (virtual transaction management system) 

[0031 ] Described below is the first feature TVirtual- 
Contract container class*. 

1 .1 According to the present embodiment, it is assumed 
that financial transactions are normally compound 
transactions (compound goods) comprising a plurality 
of transaction entities as shown in 4. 

[0062] Based on this assumption, according to the 
present embodiment, financial transactions are 
encoded based on the object-oriented concept in a 
computer, and the general risk management is realized 
based on the object-oriented concept According to the 
present invention, the object-oriented concept is not 
required. However, since it is a concept for efficiently 
supporting the structure of a general risk management 
system using a computer according to the present 
invention, the present embodiment is described below 
using an example of a system configuration based on 
the object-oriented concept 

[00S3] In the present embodiment, an abstract 
class TContracf corresponding one to one to each of 
the transaction entities is defined as shown in FIG. 5. 
The financial transactions obtained as compound trans- 
actions comprising the transaction entities are 
expressed by the container class TVirtualContract 
capable of holding any number of TContract instances. 
According to the present embodiment the financial man- 
agement controlled by such an object-oriented concept 
is referred to as a 'virtual transaction management, and 
the above described compound transactions as Virtual 
transactions'. 

[0064] For example, in the instance image of the 
'cancelable swaps', the TContract instance named 
'InterestRateSwap' corresponding to the first transac- 
tion entity and the TContract instance named 
'OptionOnSwap' corresponding to the second transac- 
tion entity are elements of the set of TVirtualContract 



instance corresponding to a virtual transaction 'cancela- 
ble swaps' as shown in FIG. 6. 
[0085] The virtual transaction management system 
is apparently complicated, but correctly reflects on a 

5 computer the procedure of a person recognizing a set of 
financial transaction entities as virtual compound trans- 
actions. That is, when a person recognizes such com- 
pound transactions as the above described cancelable 
swaps, he or she first recognizes the name indicating 

w what transactions they are (cancelable swaps), that is, 
first recognizes the virtual transactions by a collective 
name, and then takes interest in the transaction entities 
that are components (elements of a set). 
[0066] A person unconsciously recognizes a set of 

is things by its collective name using a method of simplify- 
ing a complicated event This method refers to a basic 
concept indispensable to satisfy the functional require- 
ments of the present embodiment in which virtual trans- 
actions are processed regardless of single or 

20 compound transactions. That is, in this concept, com- 
mon financial transactions are compound transactions. 
Therefore, for example, when a plain vanilla swap which 
is one of the simple formatted transactions is 
expressed, it is expressed as a virtual transaction 

25 named 'InterestRateSwap' containing only one element 
named 'InterestRateSwap' as a transaction entity as 
shown in FIG. 7. 

[0067] Thus, according to the present embodiment, 
the general risk management can be performed on var- 
30 ious f inancial transactions using a simple algorithm by a 
virtual transaction container holding a single transaction 
as well as compound transactions. 

1 .2 Class structure for realizing virtual transactions 

35 

[0068] FIGS. 5 and 8 show the structure of the class 
of virtual transactions according to the present embodi- 
ment in the object-oriented concept. 
[0069] In FIGS. 5 and 8, TCFSwap refers to a con- 

40 tainer class holding a cash flow element of various cash 
flow type transactions. TOption also indicates an 
abstract class representing each type of option. Thus, 
according to the present embodiment a class inheriting 
the TContract class and corresponding to each of the 

45 transaction entities is def ined. 

[0070] The TVirtualContract class is a container 
class having the function of holding an instance of the 
TCFSwap/TOption class corresponding to each of the 
transaction entities. The TVirtualContract instance 

so holds a link list referring to the fist structure of each 
TCFSwap/TOption instance as one of the members. 
[0071] Each of the class structures relating to the 
TCFSwap and TOption is described later. 
[0072] The excellent characteristics of the class 

55 structure shown in FIGS. 5 through 8 can be easily 
understood by assuming the procedure of performing 
current price evaluating operations on, for example, the 
compound transactions as shown in FIG. 6. 
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[0073] The TContract class holds a virtual method 
GetNPVO for performing a current price evaluating 
operation. The TCFSwap class and the TDption class 
override the virtual method. Therefore, when the Can- 
celabJeSwap (cancelable swaps) instance belonging to 
the TvirtualContract class becomes active, the result of 
the current price evaluating operation on the cancelable 
swap can be obtained by sequentially issuing the virtual 
method GetNPVO to the instances Interest RateSwap 
and OptionOnSwap of the transaction entity classes 
TCFSwap and TDption each stored in the list structure 
and inheriting the TContract class. 
[0074] Thus, according to the present embodiment 
various arithmetic operations can be performed for the 
general risk management without a conditional branch 
used in the conventional management with strings 
regardless of whether a financial transaction to be proc- 
essed is a single transaction or a compound transaction 
only by holding the TCFSwap instance or the TDption 
instance through a link list in the TVIrtual Contract. That 
is, the present embodiment has the class structure 
reflecting the highest operation efficiency from the vari- 
ations of aspects in the object-oriented concept. 

1 .3 Advantage of virtual transactions 

[0075] The advantage of the virtual transaction 
management system over the conventional technology 
is represented by the following three points. 

1.3.1 Simple program structure 

1 .3.2 High-speed operations on compound transac- 
tions 

1 .3.3 Data compression 

[0076] Sequentially described below are the above 
described points of the advantage of the virtual transac- 
tion management system. 

1 .3. 1 Simple program structure 

[0077] According to the present embodiment, all 
transactions can be expressed by one TVirtualContract 
instance without exception regardless of the type of 
transaction to be processed, or regardless of a single 
component or a plurality of components. Therefore, an 
application programmer can write a program without 
considering the type or configuration of a transaction. 

1 .3.2 High-speed operation on compound transactions 

[0078] Regardless of the introduction of the object- 
oriented concept as a system designing means, it is 
necessary, when the virtual transaction management 
system is not adopted, to perform a retrieving process 
and an aggregating process based on the association 
between transaction entities to be realized by any 
method after performing operations on each of the 



transaction entities to complete all operations for com- 
pound transactions. On the other hand, in the virtual 
transaction management system, the portion corre- 
sponding to the above described association is realized 

5 using a link list Therefore, the above mentioned proce- 
dure can be replaced with the procedure of sequentially 
accessing each pointer entered in the link list. 
[0079] Accordingly, with the increasing number of 
compound transactions to be processed, that is, the 

w more complicated the compound transactions 
becomes, a larger difference in performance between 
the operations performed according to the present 
embotfimerrt and the conventional technology can be 
expected. 

15 

1 .3.3 Data compression 

[0080] The virtual transaction management system 
also provides the function of compressing the size of the 
20 transaction attribute data in the memory or database. 
Described below is the means for realizing the function 
in a simple case. 

[0081] In financial facilities in which a large volume 
of interest rate swaps are processed, it is assumed that 

25 two interest rate swap objects as shown in FIG. 9 are 
generated as a most probable case. To identify an 
actual interest rate swap contract more detailed 
attribute information is required. However, only 
attributes required in explaining the data compression 

30 effect of virtual transactions are set in this example. 
[0082] The difference between the two contracts 
resides in contents of attributes of contractors and 
notional principals. For convenience, it is assumed that 
the first interest rate swap is named 

35 Interest RateSwapOOl , and the second interest rate 
swap is named lnteredtRateSwapO02. 
[0083] FIG. 1 0 shows a generated image of the two 
objects. FIG. 1 0 shows that each of the two TvirtualCon- 
tract instances has the three pieces of attribute data, 

40 that is, Name, Counterparty, and MotionalConvFactor, 
and the link list (LinkUst) making reference to the TCF- 
Swap instance InterestRateSwap. In this example, the 
reference address (the portion noted as SameAddress) 
to the InterestRateSwap instance stored in the link list of 

45 the TVirtualContract instance Interest RateSwap002 is 
the key to the data compression. The data compression 
can be realized with the TCFSwap instance Interes- 
tRateSwap shared by storing the same address as the 
reference address to the InterestRateSwap instance 

so stored in the link list of the TVirtualContract instance 
lnterestRateSwap002. 

[0084] However, if the above described reference 
address stored in the link list of the TVirtualContract 
instance lnterestRateSwap002 is used as is, the 
55 notional principal of the Interest RateSwap002 equals 1 
billion yen which is equal to the notional principal of the 
InterestRateSwapOOl instance. Therefore, according to 
the present embodiment a conversion factor Notional - 
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ConvFactor for use in converting a basic notional princi- 
pal (in this example, the notional principal of the 
InterestRateSwapOOl instance) into the assumed prin- 
cipal of each instance is defined in each TVirtualCon- 
tract class. That is, the value of 1 is stored in the 
InterestRateSwapOOl instance as a conversion factor 
Notional ConvFactor, and the value of 2 is stored in the 
lnterestRateSwap002 instance as a conversion factor 
Notional ConvFactor. 

[0085] Described above is the case in which the 
data compression is effective only with the same con- 
tract term, interest payment date structure, and stipu- 
lated rate, but with a different contractor and notional 
principal. However, in the virtual transaction manage- 
ment system according to the present embodiment the 
function can be extended depending on the requested 
data compression effect. For example, if the stipulated 
rate is also different between the two contracts in the 
above described case, the attribute of storing the con- 
version factor of the stipulated rate can be defined. Sim- 
ilarly, a higher data compression effect can be obtained 
by increasing the number of attributes which can be 
reproduced using conversion factors or functions. 
[0086] The data compression in the virtual transac- 
tion system according to the present embodiment con- 
tributes not only to the reduction of hardware resources 
but also to higher speed operations. 
[0087] For example, when the interest sensitivity of 
the two interest rate swaps in the case shown in FIG. 9 
is measured, it is necessary to update the current val- 
ues of the cash flow elements on each payment day of 
the interest rate swaps. In this case, in the method 
shown in FIG. 10, the update procedure is followed only 
on the InterestRateSwapOOl instance. On the 
I nterest RateSwap002 instance, the update procedure is 
completed after multiplying the value obtained in the 
above described update procedure by the conversion 
factor NotionalConvFactor. Normally, the data compres- 
sion is a negative factor in the operation speed of an 
application, but a positive factor in the virtual transaction 
management system according to the present embodi- 
ment. 

1.4 Realizing virtual transaction management system 
using RDBMS/RDB 

[0088] In a program installed based on the object- 
oriented concept, the OODBMS (object-oriented data- 
base management system) is normally used to perma- 
nently hold an instance generated in the memory. 
However, the RDBMS (relational database manage- 
ment system) is also adopted in many cases with the 
implementation cost, the utilization of existing 
resources, the stable operation results, etc. taken into 
account. In this embodiment an example of realizing a 
virtual transaction management system applied when 
the RDBMS is used to permanently hold an instance. 
[0089] To manage virtual transactions using the 



RDBMS, three tables are required to store at least the 
following three instances or lists. 

TVirtualContract instance 
5 TContract instance 

Link list in TVirtualContract instance 

[0030] These tables can be easily managed as 
shown in FIG. 11, by applying the third normalization 

10 commonly used in the RDB (relational database) man- 
aged by the RDBMS. That is, by installing the intermedi- 
ate table LinkList comprising only external keys, the 
information stored in the container of the TVirtualCon- 
tract instance can be stored. 

15 [0091] FIG. 12 shows the data structure of each 
record in a VIRTUALDEAL table which is managed by 
the RDBMS module shown in FIG. 5, stored in the RDB 
module shown in FIG. 5, and stores a TVirtualContract 
instance; an INDIVDEAL table and a DEAL_KIND table 

20 for storing a TContract instance; and a LINKLIST table 
for storing a link list in the TVirtualContract instance. A 
TCFCHAIN table, a TCF table, and each OPTION table 
in the RDB module shown in FIG. 5 store an instance in 
the TRCSwap class inherited from the TContract class, 

25 an instance in the TCF class linked to the above 
described instance, and an instance in the TOption 
class inherited from the TContract class. These 
instances are described later. 

[0092] The VIRTUALDEAL table stores the con- 
so tents of the TVirtualContract instance in each record 
assigned each virtual transaction instance identification 
code VIRTUALJD) (corresponding to the Virtual ID 
shown in FIG. 1 1) for unique identification of a TVirtual- 
Contract instance. Other field names shown in FIG. 12 
35 are provided for convenience of a managing user. 

[0093] Each record in the INDIVDEAL table holds 
an entity transaction instance identification code 
INDIV ID (corresponding to the Contract ID shown in 
FIG. 11) for unique identification of a TContract 
40 instance, and a transaction type name KIND (corre- 
sponding to the Name for each Contract ID shown in 
FIG. 1 1) which can be freely named by a user for each 
TContract instance. 

[0094] Each record in the DEALJOND table holds a 
45 transaction type name KIND and a corresponding class 
identification code TYPE for identification of a class type 
(TCFSwap class or TOption class) in a class library. 
[0095] Each record in the LINKUST table holds a 
virtual transaction instance identification code 
so VIRTUALJD and an entity transaction instance identifi- 
cation code INDIVJD, thereby associating a record 
stored in the VIRTUALDEAL table with corresponding 
records in the INDIVDEAL table, TCFCHAIN table/TCF 
table, and each OPTION table. In this case, each entity 
55 information about an instance in each TCFSwap class 
inherited from the TContract class, each TCF instance 
linked to the above described instance, and an instance 
in each TOption class inherited from the TContract 
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class is stored in the TCFSwap table, the TCF table, 
and each OPTION table described later through the 
above described INDIVJD. 

[003S] With the above described table configura- 
tion, a TContract instance (TCFSwap/TOption instance) s 
identified by the entity transaction instance identification 
code INDIVJD in the INDIVDEAL table can be associ- 
ated with a plurality of TVirtualContract instances in the 
VIRTUALDEAL table through the LINKLIST table, 
thereby allowing the data compression descrfoed above 10 
by referring to FIGS. 9 and 10. 
[0097] As described above, when the OODBMS is 
adopted as a database management system, the class 
structure shown in FIGS. 5 and 8 can be stored directly 
in the OODB without adopting the table configuration 15 
shown in FIGS. 5 and 12. 

[0038] A current price evaluating operation is per- 
formed on a virtual transaction entered in the RDB mod- 
ule shown in FIGS. 5 and 12. 

20 

step 1 : When a BookOut method which is one of the 
data access methods managed by the RDBMS 
module shown in FIG. 5 is activated, a record con- 
taining an identifier ID specified from the VIRTUAL- 
DEAL table is extracted, and a virtual transaction 2s 
instance identification code VIRTUAL- 
DEAL VI RTUALJD is obtained from the record, 
step 2: A record containing the above described vir- 
tual transaction instance identification code is 
extracted from the UNKLIST table, and an entity 30 
transaction instance identification code LIN- 
KLIST. INDIVJD is obtained from the record. There 
can be a plurality of records each of which contains 
a virtual transaction instance identification coda In 
this case, a plurality of LINKLIST.INDIVJD codes 35 
are obtained. Next, each record having an entity 
transaction instance identification code is extracted 
from the INDIVDEAL table, and a transaction type 
name INDIVDEAL KIND is obtained from each 
record. 40 
step 3: Each record corresponding to each of the 
above described transaction type names is 
extracted from the DEAL_KlND table, and each 
class identification code DEALJCIND.TYPE is 
obtained from each record. 45 
step 4: Each record containing each of the entity 
transaction instance identification codes LIN- 
KLIST.INDIVJD obtained from the LINKUST table 
in step 2 is extracted from the TCFCHAIN table and 
the TCF table or each OPTION table, and each so 
TCFSwap instance and each TCF instance, or 
each TOption instance is generated on the memory 
according to each piece of entity information con- 
tained in each record and each piece of class defi- 
nition information retrieved from a class library 55 
based on each class identification code obtained in 
step 3. 

step 5: Based on the contents of the record on the 



VIRTUALDEAL table extracted in step 1 , a TVirtual- 
Contract instance is generated on the memory, and 
a reference address to each TCFSwap instance or 
each TOption instance generated in the above 
descrbed step 4 is entered in the link list in the 
TVirtualContract instance, 
step 6: The virtual method GetNPVO of each TCF- 
Swap instance or a TOption instance referred to 
from the above described link list is followed. 

[0099] Thus, according to the present embodiment, 
a current price evaluating operation is performed on 
compound transactions only by following one virtual 
method GetNPVO regardless of the transaction entities 
of compound transactions. 

[0100] When the OODBMS is adopted, the opera- 
tion in step 6 can be directly performed without perform- 
ing the operations in the above described steps 1 
through 5. 

2. TCFSwap container class for realizing a cash flow 
type transaction entity 

[01 01 ] Described next is the frame of the TCFSwap 
container class which is the second feature of the 
present invention. 

2.1 Feature of TCFSwap container class 

[0102] As described by referring to FIG. 8, a TCF- 
Swap container class is defined as a class correspond- 
ing to a cash flow type transaction entity inheriting the 
TContract class according to the present embodiment 
[0103] The most outstanding feature of the TCF- 
Swap container is that various financial transactions 
based on 'exchange' such as an foreign exchange, lend- 
ing/borrowing, bonds, shares, commodities, inter- 
est/currency swaps, equity swaps, commodity swaps, 
etc. can be realized in this single class. In the conven- 
tional technology, corresponding classes are normally 
defined for the above described transactions. When 
transactions not corresponding to currently realized 
transaction entity classes are to be newly processed, it 
is necessary to add (newly develop) corresponding 
classes. On the other hand, according to the present 
embodiment, a cash flow type transaction entity is man- 
aged as a set of cash flow elements (hereinafter 
referred to as CashFlowLet) for each unit transaction 
period on each receipt side and payment side, and a 
TCFSwap container class is prepared to collectively 
process the TCF classes corresponding to respective 
CashFlowLets. Then, with the diversification of the stor- 
age format of each TCF class in the TCFSwap con- 
tainer class, various 'exchange-based cash flow type 
transactions' can be realized. 
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2.2 Structure of TCFSwap container class 

[01 04] The TCFSwap is a container class in which a 
set of CashFlowLets are stored, and the image of the 
instance is shown in FIG. 13. s 
[0105] In FIG. 13, each of the instances in two 
TCFChain classes named 'RecCashRows' and 'Pay- 
Cash Flows' stores a link list for reference to the link 
structure and for storing a set of instances in the TCF 
class referring to the CashFlowLet. The RecCashRows 10 
instance stores a link list for the TCF instance group 
referring to a group of CashFlowLets of the receipt side. 
The PayCash Flows instance stores a link list for the 
TCF instance group referring to a group of CashFlow- 
Lets of the payment side. 75 
[01 OS] The above described instances in the two 
TCFChain classes respectively store reference to an 
instance in the TCntYieldCurve class named 'Disc- 
Curve' and an instance in the TCntPriceCurve class 
named 'PriceCurve' respectively inherited from the 20 
TPwrGadget class named 'PricingEngine'. The TPwr- 
Gadget class provides the function of performing an 
operation of financial characteristics to realize a current 
price evaluating operation for each CashFlowLet, and 
can arbitrarily define, generate, and store the informa- 25 
tion about an yield curve (discount curve), a price curve, 
a volatility curve, a transaction unit of currencies, goods, 
policies, etc. and holiday exclusion cities. FIG. 13 shows 
only the yield curve and the price curve in the above 
described information. That is, the TCntYieldCurve 30 
class is a class in which an yield curve (discount curve) 
is defined. A discount factor at a requested date can be 
obtained by a GetFactor method installed in the method. 
The TCntPriceCurve class is a class in which a price 
curve is defined, and a price index on a requested date 35 
can be obtained by a GetFactor method installed in the 
class. The TPwrGadget class also has a virtual curve 
function described later. 

[0107] FIG. 14 shows the details of an attrbute 
group stored as a class member group in the TCFChain 40 
class. In FIG. 14, the CFList attribute corresponds to the 
link list to the link structure of the TCF instance (Cash- 
FlowLet) shown in FIG. 13, and the DiscCurve attrbute 
corresponds to the reference to the DiscCurve (TCn- 
tYieldCurve) instance shown in FIG. 13. Other attrbute 45 
groups shown in FIG. 14 define the general characteris- 
tics of the cash flow on the receipt or payment side. 
[0108] These attribute groups are set through the 
user interface described later. 

[0109] ft is obvious that the attribute groups are so 
similar to the transaction attributes of interest/currency 
swaps. That is, the spot and forward transactions such 
as an foreign exchange, lending/borrowing, bonds, 
shares, commodities, etc. are assumed to be an aspect 
of swaps. Actually, most transactions in a cash flow 55 
based on exchanging can be expressed by a collective 
format of the TCF instance and an attribute which 
defines the state of an instance. 
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[0110] FIG. 15 shows the data structure of each 
record in the TCFCHAIN table corresponding to the 
TCFChain class. Using the class member name shown 
in FIG. 14 and the field name shown in FIG. 15, the 
same information is stored by the same spellings 
excluding the differences in upper and lower cases. 
However, in FIG. 15, the UNIT#CODE field corresponds 
to the AppliedUnit member shown in 14. In FIG. 15, the 
INDIVJD field stores an identity transaction instance 
identification code, thereby linking the LINKLIST table 
or the INDIVDEAL table shown in FIG. 12 to the 
TCFCHAIN table, and realizing the process in step 4 of 
the current price evaluating operation described in 1.4 
above. In FIG. 15, the TCFCHAINJD field stores a 
TCFChain instance identification code. Also in FIG. 15, 
the SIDEJD field contains a receiptyrayment side sec- 
tion code. Furthermore, the CFList attribute shown in 14 
indicating the CashFlowLet link list is dynamically gen- 
erated based on the values of the INDIVJD field and 
the SIDEJD field when the TCFChain instance is devel- 
oped in the memory. Therefore, the field corresponding 
to the attribute does not exist in the TCFCHAIN table 
shown in 15. 

[0111] Next, FIG. 16 shows the details of an 
attribute group stored as a class member group indi- 
cated within the frame of the TCF class shown on the 
right in 13, and defines necessary and sufficient items in 
performing each index calculation on the interest, earn- 
ing rate, and price of cash flow element for each unit 
transaction period. FIG. 17 shows the data structure of 
each record in the TCF table corresponding to the TCF 
class stored in the RDB module shown in FIG. 5. 
[0112] Using the class member name shown in 
FIG. 14 and the field name shown in FIG. 15, the same 
information is stored by the same spellings excluding 
the differences in upper and lower cases. In FIG. 1 7, the 
TCFJD field stores the TCF instance identification 
code. In addition, in FIG. 17, the INDIVJD field also 
stores an entity transaction instance identification code, 
and the TCFCHAINJD field stores the section code of 
the side (receipt side/payment side) of the TCFChain 
instance linked to the TCF instance. Thus, the LIN- 
KLIST table or the INDIVDEAL table shown in FIG. 12 is 
linked to the TCFCHAIN table, and the process in step 
4 in the current price evaluating operation described in 
1 .4 above is realized. The TotalCF#PV attribute and the 
DF attribute shown in FIG. 16 are dynamically gener- 
ated when the TCF instance is developed in the mem- 
ory. Therefore, the field corresporcfng to the attribute 
does not exist on the TCF table shown in FIG. 17. 
[0113] In FIG. 16, NotionalAmnt, NonlndexCF#FV, 
TotalCF#FV, and TotalCF#PV store not only the amount 
of money, but also the transaction amounts of shares 
and goods. 

[01 14] The specification of the TCF class is not lim- 
ited to the class structure shown in FIGS. 1 3 and 1 6. For 
example, the can be a method in which the TCF class is 
a base class inherited by classes corresponding to the 
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calculation of each index of an interest earning rate, 
and price. That is, any method can be acceptable if a set 
of instances expresses various financial transactions. 

2.3 Generating TCFSwap/TCFChain/TCF instances 

[0115] The procedure of generating TCF- 
Swap/TCFChain/TCF instances is classified into two 
types, that is. a formatted transaction and a non-format- 
ted transaction. 

[0116] The procedure of generating a formatted 
transaction is described below by referring to the 
explanatory chart shown in 18 and the process flow- 
chart shown in FIG. 19. 

[0117] First, the TCFSwap instance shown in FIG. 
18 is generated by user specifying the generation of a 
cash flow type transaction through a user interface 
descrfced later. Then, using the method of the TCF- 
Swap instance, two TCFChain instances RecCash- 
Flows and PayCash Rows shown in FIG. 18 are 
generated. Then, the constructor of each TCFChain 
instance generates the TList instance named 'CFList' 
shown in FIG. 18 and used as a link list to the link struc- 
ture of the TCF instance (CashFlowLet) in each 
TCFChain instance. 

[0118] Then, the user provides any necessary 
attribute values shown in FIG. 1 4 for the two TCFChain 
instances stored in the TCFSwap instance through the 
user interface described later. 
[0119] Next, the user issues an instruction to exe- 
cute the BuildCF method through the user interface 
described later. As a result, as shown in FIG. 18, one or 
more TCF instances are generated as necessary for 
two TCFChain instances, that is, RecCash Flows and 
PayCashRows, and are linked (Add(CF)) to the link list 
CFList belonging to one of the two TCFChain instances. 
[0120] FIG. 19 shows the process flow of the 
BuildCF method issued to each TCFChain instance of 
the RecCash Rows and the PayCashRows trough the 
TCFSwap instance. 

[0121] Rrst, in the generate Dates process in step 
1 , the procedure of generating a date group required to 
process a transaction such as a receipVpayment date, 
calculation period start/end date, etc. Since the algo- 
rithm of generating the date group required to process 
financial transactions is well known, the details of the 
algorithm are omitted here. As the outline of the algo- 
rithm, the period information about each cash flow ele- 
ment is computed based on each attribute value (shown 
in FIG. 14) of PaymCenters, FixCenters, EDate, TDate, 
FDate, BDConv, EndEnd. AdjTDate, CFFeq, ResetFrq, 
RxingOffset, FixingBasis, and Payln. 
[0122] Next, in step 2, it is determined whether or 
not a value larger than 0 is set as a CF Freq attribute 
value shown in FIG. 14. The user sets a value larger 
than 0 as a receipt/payment frequency when a cash 
flow type transaction such as various swaps, etc. is gen- 
erated in the user interlace described later, and sets 0 



as a receipty>ayment frequency when other simple 
transactions such as an foreign exchange, eta 
[0123] When it is determined that the CF Freq 
attribute value is larger than 0 in step 2, each TCF 
5 instance corresponding to each CashRowLet excluding 
the first and last CashRowLets is generated in steps 3 
through 6. 

[0124] Rrst in step 3, the receipt/jpayment fre- 
quency (number of elements of CashRowLets exclud- 

w ing the first and last CashRowLets) is computed 
according to the period information generated in the 
Generate Dates process in step 1 and the receipt/|pay- 
ment frequency information (CF Freq attribute) set by 
the user, and the result is set in the member variable 

is CFCount in the TCFChain class. 

[0125] Next, in step 5, one or more TCF instances 
are generated in step 4 based on the attribute value set 
in the TCFChain instance and each of the index values 
until it is determined in step 6 that the value of the mem- 

20 ber variable CFCount has reached 0 while it is 
decreased by one at a time. 

[0126] • Actually, each attribute value (FIG. 14) of 
Roatlrtdex and Notional Amnt of the TCFChain instance 
of the current side (receipt side or payment side) set by 
25 the user is set as each attribute value (FIG. 1 6) of Float- 
Index and Notional Amnt of the newly generated TCF 
instance. 

[0127] Next each of the attribute values (FIG. 16) of 
DateFrom, DateTo, PreRxing, Rxing, Days, Years, and 

30 Paymdate is computed and set for the newly generated 
TCF instance based on the period information about 
each cash flow element generated in the Generate 
Dates process in step 1 , and the value of the member 
variable CFCount of the TCFChain instance sequen- 

35 tially updated in step 5. 

[Q128] Then, each of the attribute values (FIG. 16) 
of IntRate or Margin of the newly generated TCF 
instance is set based on the IndexVal attribute value 
(FIG. 14) of the TCFChain instance of the current side 

40 (receipt side or payment side) set by the user. The 
default of the Weight attribute is 1 , and can be individu- 
ally amended using the magic sheet described later. 
[0129] The attribute value NonlndexCF_FV (FIG. 
16) of the newly generated TCF instance is set to 0. 

45 [0130] The attribute value DF of the newly gener- 
ated TCF instance is computed and set by following the 
GetFactor method of the DiscCurve instance corre- 
sponding to the attribute value DiscCurve (FIG. 14) of 
the TCFChain instance set by the user using the 

so attribute value PaymDate set in the newly generated 
TCF instance as au argument. 
[0131] Each of the attribute values of PrePrice, 
Price, Return. lndexCF_FV, MarginCF_FV, TotalCF_FV, 
and TotalCF_PV of the newly generated TCF instance 

55 is computed in the update procedure of the TCF 
instance described later. 

[0132] The UpdateCF method of the newly gener- 
ated TCF instance is a method for following the update 
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procedure of the TCF instance described later. 
[0133] All TCF instances to be linked to the 
TCFChain instance off the current side (receipt side or 
payment side) is generated by repeatedly performing in 
the loop process in steps 4 through 6 the operation of s 
generating the above descrfoed TCF instance per- 
formed in step 4. 

[0134] When it is determined in step 6, as a result of 
the above descrfeed loop process, that the value of the 
member variable CFCount is 0, or the attribute value CF 
Freq corresponding to the receiptteayment frequency 
set by the user in step 2 is 0, it is determined by the user 
in step 7 whether or not the attribute value FinPrin- 
cAmnt off the TCFChain instance is set (Null or not). 
[01 35] If the determination in step 7 is true, then the 
last TCF instance is generated in step 8. The generating 
method is generally the same as in step 4, but a process 
off setting the attribute value FinPrincAmnt (FIG. 14) of 
the TCFChain instance set by the user as a attribute 
value NonlndexCF_FV (FIG. 1 6) of the newly generated 
TCF instance is added. 

[0136] If the determination in step 7 is false, then it 
is determined in step 9 whether or not the attribute value 
IniPrincAmrrt of the TCFChain instance has been set by 
the user (Null or not). 

[0137] If the determination in step 9 is false, it indi- 
cates an error (not shown in the attached drawings). 
[0138] If the determination in step 9 is true, then the 
first TCF instance is generated in step 10. The generat- 
ing method is generally the same as in step 4, but a 
process of setting the attribute value FinPrincAmnt 
(FIG. 14) of the TCFChain instance set by the user as a 
attribute value NonlrtdexCF_FV (FIG. 16) of the newly 
generated TCF instance is added. 
[0139] In step 1 1 after step 8 or 10, the UpdateCFs 
method is followed by the TCFChain instance of the cur- 
rent side (receipt side or payment side). When the 
method is followed, an UpdateCF method (to be 
described later) for performing a current price evaluat- 
ing operation is issued to all TCF instances linked to the 
TCFChain instance. 

[0140] Since a number of inter-bank transactions 
are formatted, transaction objects can be easily gener- 
ated by the user setting necessary parameters in the 
above described series of processes through a com- 
mon user interface described later regardless off the 
type off cash flow transaction. 
[0141] On the other hand, when the user requests 
to generate a non-formatted transaction, the attribute of 
the TCF instance group is easily amended or the TCF 
instance can be individually generated such that the 
feature of an object transaction can be reflected, and 
then the result is added to the TCFChain instance 
through the user interface referred to as a magic sheet 
described later after generating the TCFChain instance 
in the same procedure as in the case of the above 
described formatted transaction. In this case, after the 
amendment or addition, the user explicitly instructs to 



follow the above described UpdateCFs method. 
[01 42] The typical example of such a non-formatted 
transaction is an amortized/accumulation swaps that 
have no systematic schedule of notional principal. How- 
ever, in this case, since regularity normally exists in the 
configuration of an interest payment date, a computa- 
tion period, etc., the user only has to amend the 
attribute the TCF instance not corresponding to the 
rules after issuing the BuitdCF method. Therefore, indi- 
vidually generating the TCF instance is limited to a 
transaction off extremely irregular cash f taw configura- 
tion. 

[0143] As described above, the TCFChain class 
functions as a template for automatically generating a 
set of a cash flow for a formatted transaction frequently 
used in actual financial transactions. The function of the 
TCFChain class is to collectively generate a set of TCF 
instances, and the attribute values stored therein are 
not used in the arithmetic operations for measuring 
risks. The TCFChain class can be considered a class 
for absorbing the difference in various transactions 
based on the exchanging in a cash flow. 

3. Update method of the TCF instance 

[0144] The Update method implemented for the 
TCF class has the function of performing a current price 
evaluating operation in a unit transaction period corre- 
sponding to the class. This method is activated through 
the UPdateCFs method off the TCFChain class at an 
instruction to follow the GetNPVO method in the TVirtu- 
al Contract instance or the TCFSwap instance when a 
user updates any parameter through the user interface 
described later and it becomes necessary to perform a 
risk management operation. That is, according to the 
present embodiment, a current price evaluating opera- 
tion for each unit transaction period is performed inde- 
pendently by the Update method of the TCF class 
corresponding to each unit transaction period. 
[0145] In this Update method, a current price evalu- 
ating operation is performed based on the fixture value 
index computed based on one of the three types of indi- 
ces, that is, an interest, an earning rate, and a price in a 
unit transaction period, and an evaluation value inde- 
pendent of any of the indices of an interest an earning 
rate, and a price. The present value obtained by multi- 
plying the above described operation result by a prede- 
termined discount rate is defined as a result of the 
current price evaluating operation. 
[0146] The feature of this method resides in that the 
update algorithm of the cash flow conventionally pre- 
scribed for each transaction type can be expressed by 
only the three type of indices, that is, an interest, an 
earning, and a price. When any of the indices is speci- 
fied, a cash flow can be finally determined at a current 
price ratio of the DateFrom (calculation period starting 
date) and the DateTo (calculation period ending date). 
[0147] The financial transactions for payment are 
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not limited to currencies, but an foreign exchange, 
bonds, shares, commodities, eta are acceptable. In this 
case, the above descrfoed Update method is used in 
computing the future value index by computing the cur- 
rent price ratio in accordance with the interest earning 5 
rate, or price in the unit (for example, the number of 
shares) of the financial transactions for payment in the 
corresponding unit transaction period. That is. accord- 
ing to the present embodiment, the exchanging-based 
cash flow type transaction can be generally processed 
whatever unit of financial transactions is to be proc- 
essed for payment 

[0148] FIG. 20 is a process flowchart of the Update 
method of one TCF class (hereinafter referred to as a 
current TCF class). 

[0149] In step 1 , it is determined whether the Index- 
Type attribute value (FIG. 14) of the TCFChain class on 
the side to which the current TCF class specified by the 
user through the user interface described later belongs 
is an interest (IntRate), an earning rate (Return), or 
price (Price). 

[0150] If it is determined that the IndexType 
attribute value is an interest (IntRate), then the previous 
term price index attribute value PrePrice (FIG. 1 6) of the 
current TCF class is set to 1 in step 2. 
[01 51 ] In step 3, it is determined whether or not the 
Floatlndex attribute value (FIG. 14) of the TCFChain 
class on the side to which the current TCF class 
belongs is set by the user through the user interlace 
descrfoed later. 

[0152] If the Floatlndex attribute value is not set, the 
IntRate attribute value is multiplied by the Years 
attribute value in the current TCF class in step 4, and 
the multiplication result is defined as the current price 
index attribute value Price of the current TCF class. The 
IntRate attribute value of the current TCF class is cop- 
ied from the IrtdexVal attribute value (FIG. 14) of the 
TCFChain class on the side to which the current TCF 
class belongs. The IndexVal attribute value is set by the 
user through the user interface described later. In addi- 
tion, the Years attribute value indicates the number of 
years of the unit transaction period (accounting period) 
corresponding to the current TCF class set for the cur- 
rent TCF class in step shown in FIG. 19. The Years 
attribute value is computed in the Generate Dates proc- 
ess in step shown in FIG. 19 based on each of the 
attribute values (FIG. 14) of the PaymCenters, FixCent- 
ers, EDate, TDate, FDate, BDConv, EndEnd, AdjTDate, 
CFFrq, ResetFrq, FixingOffset, FixingBasis, and Payln, 
which are set by the user through the user interface 
descrfoed later, of the TCFChain class on the side to 
which the current TCF class belongs. 
[0153] Thus, when the user specifies a fixed inter- 
est then the value obtained by multiplexing the user- 
specified fixed interest value IntRate by the number of 
accounting-period years Years is defined as the current 
price index attribute value Price of the current TCF 
class. Then, in step 10, the value obtained by dividing 



the current price index attribute value Price of the cur- 
rent TCF class by the previous term price index attribute 
value PrePrice of the current TCF class is obtained by 
as the current price ratio attribute value Return (FIG. 1 6) 
in the current TCF class. In this case, since the previous 
term price index attribute value PrePrice of the current 
TCF class is set to 1 in step 2, the current price index 
attribute value Price of the current TCF class obtained 
by multiplying the user-specified fixed interest value 
IntRate by the number of accounting-period years Years 
of the current TCF class is defined as the current price 
ratio attribute value Return of the current TCF class. 
[01 54] On the other hand, if it is determined in step 
3 that the Floatlndex attribute value is set by the user, 
then the value obtained by dividing the value of the price 
curve on the calculation period ending date DateTo of 
the current TCF class by the value of the price curve on 
the calculation period starting date DateFrom of the cur- 
rent TCF class is defined as the current price index 
attribute value Price of the current TCF class in step 5. 
The value of each price curve can be computed by 
invoking the GetFactor method of the PriceCurve 
instance (FIG. 1 3) referred to by the TCFChain class on 
the side to which the current TCF class belongs using 
the calculation period starting date DateFrom or the cal- 
culation period ending date DateTo as an argument. 
The price curve can be defined and specified by the 
user through the user interface described later. 
[0155] Thus, when the user specifies a variable 
interest, the current price ratio of the price curve speci- 
fied by the user in the unit transaction period (account- 
ing period) corresponding to the current TCF class is 
defined as the current price index attribute value Price 
of the current TCF class. Then, in step 10, the value 
obtained by dividing the current price index attribute 
value Price of the current TCF class by the previous 
term price index attribute value PrePrice of the current 
TCF class is obtained as the current price ratio attribute 
value Return in the current TCF class. In this case, 
since the previous term price index attribute value Pre- 
Price is set to 1 in step 2, the current price index 
attribute value Price of the current TCF class obtained 
as a current price ratio in the unit transaction period 
from the price curve is defined as the current price ratio 
attribute value Return of the current TCF class. 
[01 56] In step 2 described above, if it is determined 
that the IndexType attribute value specified by the user 
is an earning rate (Return), then the value of the price 
curve on the calculation period starting date DateFrom 
of the current TCF class is defined as the value of the 
previous term price index attribute value PrePrice of the 
current TCF class in step 8. The method of computing 
the price curve value is the same as in step 5 above. 
[0157] Then, in step 9, the value of the price curve 
on the calculation period ending date DateTo of the cur- 
rent TCF class is defined as the value of the current 
price index attribute value Price. The method of comput- 
ing the value the price curve is the same as in step 5 
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above. 

[01 58] Then, in step 1 0, the value obtained by divid- 
ing the current price index attribute value Price of the 
current TCF class by the previous term price index 
attribute value PrePrice of the current TCF class is 
obtained as the current price ratio attribute value 
Return. 

[0159] In step 1 above, if it is determined that the 
user specified IndexType attribute value is the price 
(Price), then the previous term price index attribute 
value PrePrice of the current TCF class is set to 1 in 
step 6. 

[0160] Then, in step 7, the value of the price curve 
on the calculation period ending date DateTo of the cur- 
rent TCF class is defined as the value of the current 
price index attribute value Price. The method of comput- 
ing the value of the price curve is the same as in step 5 
above. 

[01 61 ] Then, in step 1 0, the value obtained by divid- 
ing the current price index attribute value Price of the 
current TCF class by the previous term price index 
attribute value PrePrice of the current TCF class is 
obtained as the current price ratio attribute value 
Return. In this case, since the previous term price index 
attribute value PrePrice is set to 1 in step 6, the value of 
the price curve on the calculation period ending date 
DateTo of the current TCF class is defined as the cur- 
rent price ratio attrfcute value Return of the current TCF 
class. 

[0162] As described above, the current price ratio 
attribute value Return in the unit transaction period of 
the current TCF class can be finally obtained whichever 
the user specifies among an interest, earning rate, and 
price. 

[0163] Next, in step 1 1 shown in FIG. 20, the value 
obtained by multiplying the current price ratio attribute 
value Return computed as described above by the 
notional principal amount attribute value Notional Amnt 
of the current TCF class is defined as the receipt/pay- 
ment amount attrfoute value lndexCF_FV (FIG. 16) 
based on the index in the current TCF class. The 
notional principal amount attribute value Notional Amnt 
in the current TCF class is copied from the notional prin- 
cipal amount attribute value NotionalAmnt, which is set 
by the user through the user interface described later, of 
the current TCF class on the side to which the current 
TCF class belongs. 

[0164] Then, in step 12, the value obtained by mul- 
tiplying the margin attribute value Margin in the current 
TCF class by the notional principal amount attrfoute 
value NotionalAmnt in the current TCF class is defined 
as the receipt/payment amount attribute value 
MarginCF_FV (FIG. 16) based on the margin in the cur- 
rent TCF class. The margin attribute value Margin of the 
current TCF class is copied from the IrtdexVal attrtoute 
value of the TCFChain class on the side (receipt or pay- 
ment side) to which the current TCF class belongs. 
When the user specifies a variable interest for the side 



to which the current TCF class belongs through the user 
interface described later, a margin value can be speci- 
fied as the IndexVal attribute value of the TCFChain 
class on the above described side. 

s [01 65] In step 1 3, the value obtained by multiplying 
the receipt/payment amount attribute value 
lndexCF_FV based on the index in the current TCF 
class computed in step 1 1 by the weight attribute value 
of the current TCF class, the receipt/payment amount 

io attribute value MarginCF_FV based on the margin com- 
puted in step 12, and the receipt/payment amount 
attribute value NonlndexCF_FV (FIG. 16) independent 
of the index of the current TCF class are added up, and 
the sum is defined as the total receipt/|rayment amount 

is attribute value TotalCF_FV (FIG. 1 6) of the current TCF 
class. Although the default of the Weight attribute of the 
current TCF class is 1 , the user can individually amend 
the value using the magic sheet which is the user inter- 
face described later. In addition, the receiptfaayment 

20 amount attribute value NonlndexCF_FV independent of 
the index of the current TCF class is copied from the ini- 
tial principal exchange amount IniPrincAmnt or the final 
principal exchange amount RnPrincAmrrt, which is 
verified by the user through the user interface 

25 described later, of the TCFChain class on the side to 
which the current TCF class belongs (refer to step 8 or 
10 shown in FIG. 19). 

[0166] Last, in step 14, the total receiptyayment 
amount attribute value TotalCF_FV of the current TCF 

30 class computed in step 13 is multiplied by the discount 
factor attribute value DF (PaymDate), and the multipli- 
cation result is defined as the total receipt/jpayment 
amount present value TotalCF_PV (FIG. 16). The dis- 
count factor attribute value DF (PaymDate) of the cur- 

35 rent TCF class is preliminarily computed by invoking the 
GetFactor method of the DiscCurve instance (FIG. 13) 
referred to by the TCFChain class on the side to which 
the current TCF class belongs using the receiptfcay- 
merrt date attribute value PaymDate of the current TCF 

40 class when the current TCF class is generated (refer to 
steps 4, 8, and 10 shown in FIG. 1 9). It is a factor for use 
in discounting the total receipt/payment amount 
attribute value TotalCF_FV as a future value to the 
present value. 

45 [0167] The computed total receipt/jraymerrt amount 
present value TotalCF_PV of the current TCF class is 
returned to the TVirtual Contract instance or the TCF- 
Swap instance as a return value of the GetNPVO 
method in the TVirtualContract instance or the TCF- 

50 Swap instance through the UpdateCFs method of the 
TCFChain class. 

[01 68] In the GetN P VO method in the TVirtualCon- 
tract instance or the TCFSwap instance, the total 
receipt/payment amount present value TotaICF_PV 
55 returned from the current TCF class belonging to each 
side is added on each side (receipt side and payment 
side), that is, for each TCFChain class. Each present 
value PV which is the sum on each side and a total 
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present value NPV which is obtained by adding each of 
the present values are displayed on the user interface 
descrfoed later. 

[0169] As descr&ed above, when the user amends 
any parameter through the user interface descrfoed s 
later, a new present value can be immediately recom- 
puted, thereby realizing efficient risk management. 
[0170] The procedure of designing and generating 
a TCFSwap class for realizing cash flow type transac- 
tions has been described. The actual generation of an 
instance for cash flow type transaction is classified and 
described below. 

[01 71 ] As descrbed above, the TCFSwap can gen- 
erate most transactions in which cash flows are 
exchanged. However, it is necessary to classify the 
transactions to be processed depending on the basic 
characteristics when the transactions are actually gen- 
erated. 

[0172] The cash flow type transactions are classi- 
fied as follows based on each characteristic. 

1) Exchanging principal of Afferent types 

In the explanation, the principal indicates Non- 
lrtdexCF#FV set for the TCFChain class, that is, 
indicates a cash flow determined independently of 
indices. 

2) Exchanging principals of the same type on a time 
axis 

3) Exchanging a cash flow generated using indices 
of different types 

4) Exchanging a cash flow generated using indices 
with a principal on a time axis 

[0173] FIG. 21 is a table showing the above 
described classification associated with the typical 
transactions in the market. On the table, the shares and 
forward goods transactions are displayed with the clas- 
sification number 2 and 4, because these transactions 
can be expressed by either aspect. Depending on the 
recognition of a transaction, other classification can be 
realized. The classification is not fixed, but can be vari- 
able as long as the features of each transaction can be 
effective. Furthermore, some transactions can be 
obtained as a combination of classes. Currency swaps, 
etc. correspond to this type of transaction, and can be 
expressed as a combination of classification numbers 1 
and 3. 

4. TOption container class for realizing option type 
transactions 

[01 74] Described below is the frame of the TOption 
container class as the fourth feature of the present 
invention. 

4.1 Feature of the TOption container class 
[0175] The cash flow type transaction expresses a 



number of transactions realized by diversifying the for- 
mat of a set of simple cash flow elements (Cash Flow- 
Let). On the other hand, the option type transaction 
expresses transactions by diversifying a method. That 
is, the price evaluation (current price evaluation) of the 
cash flow type transaction can be defined in an inte- 
grated method while the option type transaction indi- 
cates a different price evaluation model for each 
transaction type, and also indicates different evaluation 
models even for the same transaction type. 
[0176] Implementing different evaluation methods 
on each price evaluation model provides a virtual 
method for price evaluation for an abstract option class. 
An actual price evaluation method can be easily real- 
ized by implementing the virtual method in the entity 
class of an inheriting option. 

[0177] The outstanding feature of the option class 
realized accord ng to the present embodiment resides 
in the process of original assets, ft is common that the 
entity class of an option is provided with an attribute of 
defining the original assets in addition to the attribute of 
the corresponding option. In this system, for example, 
the following option classes can be provided. 

1) Black sholes model class for foreign exchange 

2) Black sholes model class for shares 

3) Black sholes model class for commodities 

[0178] That is, the 'original assets + evaluation 
model' defines one option class. On the other hand, 
according to the present embodiment the original asset 
attribute is implemented in an abstract option class as a 
reference to a link list. That is, the abstract option class 
has the function of a container for storing any number of 
arbitrary original asset instances. 

4.2 Data structure of TOption container class 

[01 79] TOption refers to an abstract class inheriting 
the abstract contract class TContract (refer to FIGS. 5 
and 8). FIG. 22 shows the structure and an instance 
image of the TOption. FIG. 23 shows the outline of each 
attribute and method. 

[0180] In FIG. 22, the TOption instance stores a link 
list named 'Underlying* which refers to the structure of a 
list storing a set of TContract classes that are original 
asset classes. 

[0181] The TOption instances store references to 
an instance of the TCntYirldCurve class named 'Disc- 
Curve', and an instance of the TCntVolaCurve class 
named *V6laCurve' inherited from the TPwrGadget 
class. 

[0182] As clearly indicated in these figures and 
tables, the TOption instance stores an attribute essen- 
tially required as an option, and any number of arbitrary 
original asset instances (TContract), and after specify- 
ing any of the variable parameters of the original asset 
to be compared with a strike, instructs the original asset 
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instance to perform a necessary arithmetic operation. A 
variable parameter refers to an index by which an inter- 
est, an earning rate, a price, etc. are multiplied, and a 
rate to be compared with the strike of an option such as 
an exchange rate, NPV, etc. 

4.3 Advantage by utilizing a TOption container class 

[0183] The advantage by utilizing a TOption con- 
tainer class is the following two points. 

4.3.1 Reduction of the code size and the number of 
classes 

4.3.2 High-speed simulation 

[0184] Each of the advantageous points is 
described below. 

4.3.1 Reduction of the code size and the number of 
classes 

[0185] Since the TOption instance can store any 
original asset instance at a run-time, a process is 
required to determine which is the parameters to be 
compared with the strike in the stored instances. When 
it is determined, the TOption instance invokes a 
GetATM method for computing the at-th e-money (here- 
inafter referred to as an ATM) level to be implemented in 
an instance of the original asset class. A resultant return 
value is passed to the parameter of the GetNP V method 
of the TOption instance, thereby terminating the execu- 
tion of the price evaluating method. 
[0186] Thus, the TOption class only instructs the 
original asset instance held by the TOption class to 
present an ATM level, and an actual ATM operation is 
performed by the original asset instance. It is important 
that the ATM level operation is not only required for the 
original asset of an option, but also is required when it 
independently exists (not held by the option instance) at 
the run-time of pricing, etc. 

[0187] That is, the TOption instance can efficiently 
implement its own price evaluating method by utilizing a 
method preliminarily provided for the original asset 
instance. 

[0188] In addition, the entity classes of the option 
inherited and implemented only has to be provided with 
an evaluation equation unique to its price evaluation 
model by implementing the procedure of obtaining an 
ATM level on the TOption. That is, it also can be 
assumed that these entity classes exist to present refer- 
ence to a code area in which each price evaluating 
method is stored in memory. With the similar back- 
ground, the classification described in 1) through 3) in 
4.1 above is not required, but only a Black-Sholes class 
is required, thereby reducing the number of classes. 



4.3.2 High-speed simulation 

[01 89] It is a common process of analyzing a risk of 
an option to set an evaluation date to a future point and 

5 the option value at the point is computed. According to 
the present embodiment, since a system of generating 
and holding an original asset instance when a TOption 
instance is generated is adopted, a high performance 
can be presented at a run-time of the above described 

w fixture price simulation. 

[01 SO] A problem with the above described simula- 
tion arises when a set future date comes when or after 
the corresponding option enters an in-the-money state. 
In this case, the price fluctuation analysis is not per- 

75 formed as an option, but, assuming that the right is 
effected, the price should be analyzed on a generated 
original asset 

[0191] At this time, in the system according to the 
present embodiment since the original asset instance 

20 is preliminarily generated and held, the corresponding 
TOption instance only has to make the original asset 
instance outstand when the in-the-money state is 
entered. That is, in the out-of-the-money state, the orig- 
inal asset instance exists, but the current price of the 

25 instance is ignored, and is replaced with the current 
price of the TOption instance. When the in-the-money 
state is entered, the process of replacing the current 
price of the TOption instance with the current price of 
the original asset instance. 

30 [01 92] When this method is not adopted, it is neces- 
sary to follow the procedure of generating an original 
asset when the option enters the in-the-money state, 
thereby performing an operation with a heavy load. This 
is the advantage of the system according to the present 

35 embodiment 

5. Function of defining a financial curve 

[0193] As described above, the TCFChain instance 

40 or TOption instance belonging to the TCFSwap instance 
holds reference to each curve instance inherited from 
the TPwrGadget class, and the provided financial curve 
characteristic can be utilized (FIGS. 13 and 22). 
[0194] The TPwrGadget class optionally defines, 

45 generates, and holds the information about the yield 
curve (TCntYieJdCurve class), a price curve (TCrrt Price- 
Curve class), a volarrry curve (TCrrt VblaCurve class), 
transaction units (TUnit class) such as currencies, 
goods, policies, etc., and a holiday exclusion city 

so (TCenter class). 

[0195] As described by referring to FIG. 13, the 
TCFChain container class storing a set of instances of 
the TCF class which is CashFlowLet holds reference to 
a TCntYieldCurve instance in a DiscCurve (discount 

55 curve), and a TCntPriceCurve instance in a PriceCurve 
(price curve), and obtains a discount factor and a price 
index on each request date by the GetFactor method 
implemented in the TCntYieldCurve and the TCntPrice- 
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Curve. 

[0196] Furthermore, as described by referring to 
FIG. 22, the TOption class holds reference to the TCn- 
tYiefdCurve in the DiscCurve (discount curve), and to 
the TCntVolaCurve instance in the VolaCurve (volarity 
curve), and obtains a discount factor and a volarity in 
the GatFactor method and the GetVola method. 
[01 97] In addition, in the TPwrGadget class accord- 
ing to the present embodiment, a Virtual curve* method 
expressed in the container class TCntVlrtualCurve in 
which any number of curve instances can be held is 
adopted. By providing a computing method for a virtual 
curve, a ^>ecrfic operation can be performed on a dis- 
count factor or a price index obtained in the GetFactor 
method of each curve instance held in a container (for 
example, averaging a price index). Thus, the present 
embodiment can also provide the function of combining 
a plurality of curve instances. 

[0198] Although not shown in the attached draw- 
ings, the functions of combining the yield curve (TCn- 
tYieUCurve) with the Futures (TCntFuturesCurve), and 
the price curve (TCntPriceCurve) with the add-on (TCn- 
tAddOn) can also be added according to the present 
embodiment. 

6. User Interface 

6.1 Outline of User Interface 

[01 99] The present embodiment can provide a user 
interface capable of easily changing a parameter for risk 
management and displaying a simulation result. 
[0200] In this embodiment, a new concept of provid- 
ing an input form with the classification of 1) Cash 
Flows, and 2) options, and 3) Listed is adopted. For 
example, in the conventional system, an input form (or 
screen) has been provided for each transaction type 
such as a spot foreign exchange transaction, an foreign 
exchange swap transaction, an interest rate swap trans- 
action, etc. On the other hand, the present embodiment 
inputs these transactions through one interface for 
'Cash Flows* transactions. 

[0201 ] Unlike a common general management sys- 
tem in which operations are performed with more diffi- 
culty and with more complicated financial transactions, 
the user of the system is presented with excellent con- 
venience that the user can access a desired form only 
by specifying the category of an object transaction. 

6.2 Outline of the procedure of inputting a cash flow 
transaction 

[0202] First, in the following explanation, a left click' 
or a 'right dick* refers to an operation of one clicking of 
the left or right mouse button. A left double click' refers 
to an operation of two quick clickings of the mouse but- 
ton. 'Dragging and dropping the mouse from A to B' 
refers to pressing the left mouse button at the position 



A, moving the cursor to the position B wit the button 
pressed, and releasing the pressed left button at the 
position B. 

[0203] FIG. 25 shows the main control panel 
5 according to the present embodiment. 

[0204] FIG. 26 shows the initial window screen on 

which a cash flow transaction is processed. FIG. 27 

clearly emphasizes each portion shown in FIG. 26. 

[0205] First each tab area is described. 
io [0206] In a 'Primary' tab area, a parameter for use 

in prescribing a transaction type and generating a date 

is specified. 

[0207] In a 'Commodity/Discount* tab area, a 
receipt/payment currency (or a unit of goods) and a dis- 
15 count curve are specified. 

[0208] A 'Principal Cash Rows' tab area is used 
when the initial and final exchange principals of an 
exchange, an foreign exchange swap, and a currency 
swap are input in the area where the amount of principal 
20 which is to be directly exchanged and is not related to a 
notional principal is specified. 
[0209] In a 'Return Properties (1)' tab. area, the 
basic conditions of a cash flow generated by multiplying 
a notional principal by any index of an interest, an earn- 
as ing rate, and a price is specified. According to the 
present embodiment, this cash flow is referred to as an 
'IndexCF. 

[0210] In a 'Return Properties (2)' tab area, the 
extension conditions for processing a cash flow not 
30 processed in the 'Return Properties (1)' tab area are 
specified, and non-daily items such as a receipt/jaay- 
ment date and a price determination date are gener- 
ated. 

[0211] In a 'Centers' tab area, a holiday exclusion 
35 city to be referred to when a receipt/jaayment day and a 
price determination day are determined is specified 
independently between a reception side and a payment 
side. 

[0212] Then, each of the icons, buttons, and fields 
40 in each of the above described tab areas is described 
below. 

[021 3] The object currently being generated can be 
deleted by dragging and dropping the mouse from the 
helmet icon in the 'Primary tab area to the dust box icon 
45 in the area. 

[0214] A transaction object can be designed and 
stored by a left double click on the helmet icon in the 
'Primary' tab area. 

[0215] A magic sheet indicating the details of a 
so transaction object can be displayed by dragging and 
dropping the mouse from the shake-hands icon (a vari- 
ation from the helmet icon but not shown in the draw- 
ings) to the magnifying glass in the 'Primary' tab area. 
[0216] A list of transaction type definitions can be 
55 displayed by a left click on the list field in the 'Kind' area 
in the 'Primary' tab area, thereby selecting a defined 
transaction type. When a transaction type is selected, 
the necessary input fields on the form are highlighted, 
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and the initial value is assigned in each field. The user 
can freely add and amend an invoked transaction type 
definition. 

[0217] By a left dick of the 'Change Side* button in 
the Primary 1 tab area, a group of parameters specified 
by the receipt side and the payment side described later 
can be collectively exchanged on both sides. For exam- 
ple, if the button is clicked when a parameter group of 
'selling dollars/buying yen* is specified on the form, the 
"buying dollars/selling yen' parameter setting state is 
entered. 

[0218] In the 'Business Day Conv* field in the 'Data 
Generation* area of the Primary' tab area, a holiday 
exclusion system can be specified, and *Modrfied\ fol- 
lowing', Preceding', or 'No Adust' can be specified. The 
set values are set as the BDConv attrfoute values (FIG. 
14) of each TCFChain class on the receipt side and the 
payment side. 

[021 9] In the 'Centers' field in the 'Data Generation' 
area of the Primary' tab area, a holiday exclusion city 
can be displayed. The city information can be prelimi- 
narily defined by the TPwrGadgef function described 
later. The set value is set as a PaymCenters attrbute 
value (FIG. 14) in each TCFChain class on the receipt 
side and the payment side. 

[0220] In the Today* field in the 'Data Generation* 

area of the Primary' tab area, an evaluation base date 

(transaction date/today) can be specified. 

[0221] In the 'Spot* field in the 'Data Generation' 

area of the Primary' tab area, a spot date (Spot 

Date/Settlement Date) can be specified. 

[0222] In the 'Effective' field in the 'Data Generation' 

area of the Primary' tab area, an effective date can be 

specified. The set value is set as an EDate attribute 

value (FIG. 14) of each TCFChain class on the receipt 

side and the payment side. 

[0223] In the 'Stub' field in the 'Data Generation' 
area of the Primary' tab area, the next receipt/payment 
date can be specified. The set value is set as an FDate 
attribute value (14) of each TCFChain class on the 
receipt side and the payment side. 
[0224] In the 'Maturity' field in the 'Data Generation' 
area of the Primary' tab area, a termination date can be 
specified. The set value is set as a TDate attribute value 
(FIG. 14) of each TCFChain class on the receipt side 
and the payment side. 

[0225] In the 'End End* check box in the 'Data Gen- 
eration' area of the Primary' tab area, an end-of-mortth 
roll specification can be designated. The set value is set 
as an ErtdEnd attribute value (FIG. 14) of each 
TCFChain class on the receipt side and the payment 
side. 

[0226] In the 'AdjMty* check box in the 'Data Gener- 
ation' area of the Primary' tab area, a termination date 
shift specification can be designated. The set value is 
set as an AdjTDate attribute value (FIG. 14) of each 
TCFChain class on the receipt side and the payment 
side. 



[0227] TTien, in the 'Commodity' field in the *Rec(+)' 
area and the Pay(-)' area in the 'Ck>mrnodrty/Discourrt' 
tab area, a receipt/jpayment currency or a unit of goods 
can be specified. The currency or the unit can be prelim- 

5 inarily defined by the defining function ('PwrGadget' 
function) of the financial characteristic descrbed later. 
The set value is set as an AppliedUnit attribute value 
(FIG. 14) of the TCFChain class corresponding to the 
receipt side or the payment side (hereinafter referred to 

10 as a target side) correspond ng to the *Rec(+)' area or 
the Pay(-)' area. 

[0228] In the 'DiscCurve' field in the 'Rec(+)' area 
and the Pay(-)' area in the 'Commodity/Discount' tab 
area, an yield curve for discount of a cash flow group in 

is each of the receipt side and the payment side can be 
specified. In addition, when a target transaction id a 
spot exchange, and the evaluation base date set in the 
Today* field in the 'Data Generation' area of the Pri- 
mary' tab area is today, a curve lor discount from the 

20 spot date to today set in the 'Stub' field in the area can 
be specified. These curves can be preliminarily defined 
by the defining function ('PwrGadgef function) of the 
financial characteristic described later. The set value is 
set as a DiscCurve attribute value (FIG. 14) of the 

25 TCFChain class corresponding to the target side. 

[0229] Then, the arrow gauge at the center of the 
Principal Cash Flows' tab area can preserve the base 
currency side when a principal is exchanged. For exam- 
ple, when Rec:'USD'/Pay:'JPV (buying dollars/selling 

30 yen) is specified, the dollar base is adopted as 
'1USD=130.05JPV if the 'Rec' is specified as the base 
side. On the other hand, if the 'Pay' is specified as the 
base side, then the yen base is adopted as 
'1JPY=0.0076894USD. 

35 [0230] In the field in line 1 below the arrow gauge, 
the initial principal exchange rate is tisplayed, and the 
final term principal exchange rate is displayed in the 
field in line 2. Based on the gauge specification and the 
rate displayed in these fields, the amount of a currency 

40 based on the base currency is automatically computed. 
[0231] In each field in line 1 of the 'Initial: Pay(- 
J/Final: 'Rec(+)' area and the 'Initial: Rec(+)/Fina!: Pay(- 
)' area in the Principal Cash Rows' tab area, an actual 
amount of a principal to be exchanged (initial principal 

45 exchange amount) on the effective date set in the 'Effec- 
tive' field in the 'Data Generation' area of the Primary' 
tab area can be specified for exchange swaps and cur- 
rency swaps. The set value is set as an IniPrincAmnt 
attribute value (FIG. 1 4) of the TCFChain corresponding 

so to the target side. 

[0232] In each field in line 2 of the 'Initial: Pay(- 
)/Final: *Rec(+)* area and the 'Initial: Rec(+)/Final: Pay(- 
)' area in the Principal Cash Rows' tab area, an actual 
amount of a principal to be exchanged (final principal 

55 exchange amount) on the maturity date set in the 'Matu- 
rity* field in the 'Data Generation' area of the Primary* 
tab area can be specified for exchange swaps and cur- 
rency swaps. The set value is set as an FinPrincAmnt 
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attribute value (FIG. 1 4) of the TCFChain corresponding 
to the target side 

[0233] Next, the arrow gauge at the center of the 
'Return Properties (1)' tab area prescribes the base cur- 
rency side at the exchange off a notional principal when s 
a coupon swap, etc. is input The function is the same as 
in the case of the mow gauge at the center in the 'Prin- 
cipal Cash Flows' tab area. 

[0234] In the field of the above described arrow 
gauge, a notional principal exchange rate is displayed. 10 
Based on the above described gauge specification and 
the rate displayed in these fields, the amount of a cur- 
rency based on the base currency is automatically com- 
puted. 

[0235] Using each 'Notional' radio button in the is 
'Rec(+y area and the 'Pay(-)* in the 'Return Properties 
(1)' tab area, a notional principal definition of either the 
fixed principal system ('FrxedYFixed Notional Principal') 
or the variable principal system (Var*: Variable Notional 
Principal 1 ) can be specified. The set value is set as a 20 
VarNotional attribute value (FIG. 14) of the TCFChain 
class corresponding to the target side. 
[0236] In the 'Notional' field in the 'Rec(+)' area and 
the 'Pay(-)' in the 'Return Properties (1)' tab area, the 
notional principal amount can be specified when the 25 
plain vanilla transaction is processed, and the initial 
notional principal can be specified when the notional 
principal is not constant. The set value is set as a 
NotionalAmnt attribute value (FIG. 14) of the TCFChain 
class corresponding to the target side. 30 
[0237] Using each 'IndexType* radio button in the 
'Rec(+)' area and the 'Pay(-)* in the 'Return Properties 
(1)' tab area, an index of an interest flnf), an earning 
rate (*%chg*), or a price ('Prx') can be defined. The set 
value is set as an IndexType attribute value (FIG. 14) of 35 
the TCFChain class corresponding to the target side. 
[0238] In each 'Index/Value' field in the 'Rec(+)' 
area and the 'Pay(-)' in the 'Return Properties (1)' tab 
area, an index value and its unit f%', bp', 'dec*) can be 
specified. The set value is set as an IndaxVal attribute 40 
value and an IndexUnit attribute value (FIG. 14) of the 
TCFChain class corresponding to the target side. 
[0239] Each gauge on the left side of each of the 
above described 'Index/Value' fields can specify either 
the fixed ('FX*) or the variable ('FL*) index definition. The 45 
set value is set as a Floatlndex attribute value (FIG. 14) 
off the TCFChain class corresponding to the target side. 
[0240] In each 'ReturnCurve' field in the *Rec(+)' 
area and the *Pay(-)' in the 'Return Properties (1)' tab 
area, a forward price curve or an yield curve in each of so 
the receipt side and the payment side can be specified. 
The forward price curve is specified when a transaction 
such as 'Forward Forex', 'Equity Swaps', 'Commodity 
Swaps', etc. is defined. The yield curve is specified 
when a transaction such as 'Interest Rate Swaps', etc. ss 
is defined. These curves can be preliminarily defined by 
the defining function fPwrGadgef function) of the finan- 
cial characteristic described later. The set value is set 



as a PriceCurve attribute value (FIG. 14) of the 
TCFChain class corresponding to the target side. 
[0241 ] In each of the 'D-Cnt + C/R-Frq' field group in 
the 'Rec(+)' area and the 'Pay(-)' in the 'Return Proper- 
ties (1)' tab area, a daily value computation system 
CAci/360\ 'Act/365Fixed\ 'Act/Act', 1 30/360\ '30E/360'), 
a receiptfcayment frequency (payment intervals), and a 
reset frequency can be specified. The set value is set as 
a DayCount attribute value, a CFFrq attrbute value, and 
a ResetFrq attribute value (FIG. 14) of the TCFChain 
class corresponding to the target side. 
[0242] In the 'Round/Trunc' field group, a rounding- 
off ((RndT/truncation (Trc 1 ), and their effective digits can 
be specified. The set value is set as a Rounding 
attribute value and a DecPlaces attribute value (FIG. 
14) of the TCFChain class corresponding to the target 
side. 

[0243] FIG. 27 shows the activation off necessary 
parameters. First, after a left click on the key icon at the 
lower left on the screen, a right click is made on a 
desired parameter, a left click is made on the 'Active' 
property, and then the result is checked. A large number 
of portions are made active for interest rate swaps. 

6.3 Procedure of generating interest rate swaps 

[0244] In this step, interest rate swaps which refer to 
exchange between yen and yen in the cash flow, that is, 
yen/yen swaps are performed. 
[0245] First a currency is selected in each 'Com- 
modity* field in the 'RecW area and the 'Pay(-)' in the 
'Commodrty/Discount' tab area at the upper hahf on the 
screen. 

[0246] Then, in the 'DisCurve' field in each area, 
'LIBOR&SWAP' is specified as an yield curve character- 
istic corresponding to the selected currency. 
[0247] Then. In each 'ReturnCurve' field in the 
'Rec(+)* area and the 'Pay(-)' in the Return Properties 
(1)' tab area at the lower naff on the screen, 
'LIBOR&SWAP* is specified as a return curve character- 
istic. The return curve is a forward cash flow, that is, the 
base in computing the future interest 
[0248] In each 'D-Cnt + C/R-Frq' field group in the 
'Rec(+)' area and the 'Pay(-)' in the Return Properties 
(1)' tab area, each value is set according to the market 
convention. 

[0249] Thus, the generated parameter set can be 
assigned a name using a dialog box displayed by a left 
click on the icon to the right of the key icon at the lower 
left on the screen as shown in FIG. 28. In this example, 
for example, the name 'JPY/JPY#SWP' is assigned. 
This name is entered in the list field in the 'Kind' area of 
the 'Primary tab area at the upper left on the screen. 
Afterwards, when the name is selected, the correspond- 
ing parameter set can be invoked. 
[0250] Now, 4-year-term interest rate swap goods 
are generated. First, as shown in FIG. 29, the Today' 
field, 'Spot* field, 'Effective' field, and 'Maturity' field in 



21 



41 

the 'Data Generation' area at the left on the screen are 
sequentially set. 

[0251 ] Then, as shown in FIG. 30, In each 'Notional' 
field in the 'RecW area and the *Pay(-)' in the 'Return 
Properties (1 )' tab area at the lower half on the screen, s 
1 ,000,000,000 Japanese Yen is set . 
[0252] In addition, based on the fixed rate (fixed 
interest) (selecting 'FX' in the *Rec(+)' area of the 
'Return Properties (1)' tab area), the interest rate swap 
by paying a float (selecting 'FL' in the 'Pay(-)' area) is io 
set In this case, in each 'Index/Value* field in the 
*Rec(+)' area in the 'Return Properties (1)' tab area, the 
pricing of, for example, 1 .75527% is set as a fixed rate. 
This means the PB of the payment amount equals the 
PB of the receipt amount in the transaction if the is 
'LIBOR* rate for the future 4 year float is paid and, in 
return, the fixed interest of 1 .75527% is received. 
[0253] Then, by a left double click on the helmet 
icon in the 'Primary' tab area at the upper left on the 
screen shown in FIG. 30, the icon changes into the so 
shake-hands icon as shown in FIG. 31. and the cash 
flow object can be set for the above defined swaps. In 
this example, the procedure of generating the TCF- 
Swap/TCFChain/TCF instance described in 2 and 3 
above is followed. 25 
[0254] The details of the cash flow object can be 
confirmed and changed through the magic sheet dis- 
played as shown in FIGS. 32 through 34 by dragging 
and dropping the mouse from the shake-hands icon to 
the magnifying glass icon in the 'Primary' tab area at the 30 
upper left on the screen shown in FIG. 31 . In each area 
of the 'REC tab and the 'PAY tab, the details can be 
confirmed and amended for each cash flow period 
within a specified period (four years in this example) on 
the receipt side and the payment side. 35 
[0255] Each line displayed here corresponds to 
each TCF instance referred to from the TCFChain 
instance corresponding to each of the receipt side and 
the payment side. Each field in each line corresponds to 
each attribute value (refer to FIG. 16) held by each TCF 40 
instance. When a field has no hand mark added in line 
1 , the value can be updated for new pricing. For exam- 
ple, when a value of the 'NotionalAmrrt' field (equivalent 
to the 'Notional" field) is changed, and the 'Update' icon 
is left-clicked, a new pricing is performed. In this case, 45 
the update method of the TCF instance described in 3 
above is followed. 

[0256] In FIGS. 32 through 34, a magic sheet of the 
'REC tab area on the receipt side is displayed. In FIG. 
35, a magic sheet of the 'PAY* tab area on the payment so 
side is displayed. 

6.4 Procedure of generating equity swap transactions 

[0257] Next, an equity swap transaction is gener- ss 
ated. FIG. 36 shows an example of the setting screen. 
In this example, at the float rate (variable interest) 
depending on the 'Nikkei Forward', which is a return 
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curve characteristic set in the 'ReturnCurve' field 
(selecting the 'FL in the 'Rec(+)' area of the Return 
Properties (1)' tab area), the swap in which the floating 
'LIBOR' rate (similarly selecting the 'FL' in the 'Pay(-)' 
area) is paid is set. In this case, in each 'Index/Value' 
field in the *Pay(-)' area in the 'Return Properties (1)' tab 
area, a margin rate of, for example, -1.10993% can be 
set for pricing. 

[0258] FIG. 37 shows a magic sheet of the equity 
swap object generated as described above. In this 
example, each value of the 'PrePrice' field can be com- 
puted based on the return curve characteristic 'Nikkei 
Forward' (refer to step 8 shown in FIG. 20). 

6.5 Procedure of generating foreign exchange transac- 
tions 

[0259] Then, foreign exchange transactions are 
generated. FIG. 38 shows a screen on which foreign 
exchange transactions are generated. In this example, 
the US dollars set in the field (final principal exchange 
amount field) in line 2 of the 'Initial: Pay(-)/FinaJ : 'Rec(+)* 
area are to be bought When a left double click is made 
on the no-name field at the center of the 'Principal Cash 
Rows' tab area, the current exchange rate is displayed. 
If the rate is acceptable, the amount in Japanese Yen 
set in the field (final principal exchange amount field) in 
line 2 of the 'Initial: Rec(+)/Final: 'Pay(-)' area in the 
'Principal Cash Rows' tab area is to be paid. 
[0260] FIGS. 39 and 40 show a magic sheet of for- 
eign exchange transactions generated as described 
above. The data structure is the same as in the swap 
transactions. However, a foreign exchange transaction 
contains only one cash flow (1). According to the char- 
acteristics of foreign exchange transactions, no values 
are stored in the 'Notional Am nf field and the 
'lndexCF#FV field, etc. computed based on the 'Notion- 
alAmnf field. Instead, as shown in FIG. 39, the value of 
the US dollar set in the field (final principal exchange 
amount field) in line 2 of the 'Initial: Pay(-)/Rnal: 'Rec(+)' 
area of the 'Principal Cash Flows' tab area is set in the 
'NonlndexCF#FV field of the 'REC tab area In addition, 
as shown in FIG. 40, a minus value in Japanese Yen set 
in the field (final principal exchange amount field) in line 
2 of the 'Initial: Rec(+)/Final: Pay(-)' area is set in the 
'NonlndexCF#FV field of the 'PAY' tab area. The value 
in the 'NPV field is 0 as the balance between the PV 
value (FIG. 39) on the receipt side and the PV value 
(FIG. 40) of 0 on the payment side. 

6.6 Procedure of defining financial characteristics ('Pwr- 
Gadget' function) 

[0261 1 Described below is the procedure of defining 
various financial characteristics ('PwrGadgef function). 
FIG. 41 shows an initial screen of the 'PwrGadgef func- 
tion. Displayed in the 'Curve Yard' tab area on the 
screen are: the 'Yield' Hem for definition of an yield 
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curve; the 'Price* item for definition of a price curve; the 
'Future* item for definition of a future curve; the "vola" 
item for definition of a volatility curve; the Virtual' item 
for definition of a virtual curve; the Unit' item for defini- 
tion of a transaction unit; and the 'Center' item for def ini- 5 
tion of a holiday exclusion city. 
[0262] When a left double dick is made on the 
'Center' item of the 'Curve Yard* area, the detailed items 
for definition of holiday exclusion city are displayed as 
shown in FIG. 42. In this example, holiday exclusion 
information can be defined for each city. 
[0263] When a left double click is made on the *Unif 
item of the 'Curve >ferd' area, the detailed items for def- 
inition of transaction units are displayed as shown in 
FIG. 43. In this example, a currency transaction unit, a 
unit of shares of a specific company, an oil unit, credits, 
etc. can be freely defined. 

[0264] When a left double dick is made on the 
Yield' item of the 'Curve Yard' area, the detailed items 
for definition of an yield curve are cfisplayed as shown in 
FIG. 44. In the 'Rate on Grid' tab area shown in FIG. 44, 
the screen for definition of an yield curve named 
'LIBOR&SWAP(JPY/JPY) is displayed. First as shown 
in the 'Curve Yanf tab area shown in FIG. 45, a grid for 
every two months, every two years, etc. can be freely 
defined. In this case, the details of the attribute of each 
grid are omitted here, but can be defined in the 'Linked 
Object' tab area shown in FIG. 45. Then, for each grid 
displayed in the 'Rate on Grid' tab area, a rate can be 
defined in the 'Rate' field, thereby defining a curve. 
[0265] The rate for the 'Rate' field can manually set, 
but can also be set by, for example, periodically obtain- 
ing the rate through a network (digital feed). 
[0266] When a left double dick is made on the 
'Price' item of the 'Curve \krd' area, detailed items for 
definition of a price curve are displayed as shown in 
FIG. 46. In this example, a curve such as the Nikkei 
Index, etc. with which the future value can be directly 
observed can be defined as in the yield curve shown in 
FIGS. 44 and 45. In this case, a price is directly input to 
the 'Rate' field of the 'Rate on Grid' tab area. 
[0267] FIG. 37 shows the screen on which a price 
curve is defined for a commodity (goods) such as oil, 
etc. In a commodity, a spot price is not associated with 
a future price. Then, as shown in the 'Rate on Grid' tab 
area, only the 'spf grid is defined. 
[0268] When a left double click is made on the Vir- 
tual' item of the 'Curve Yard* area, the detailed items for 
definition of a virtual curve are displayed as shown in 
FIG. 48. In this example, as shown below the Test' item 
of the 'Curve Yard' tab area, other plural curves such as 
the yield curve, the price curve, etc. are collectively 
entered in a container, and a function (operations 
method) among the plurality of curves is defined, 
thereby defining a new virtual curve. For example, in 
FIG. 48, in the 'GalcMethod' field in the 'Linked Object 
tab area, the operations among the curves can be 
defined. For example, the 'AverageMethod' method per- 



forms an operation for an averaging the corresponding 
values of a plurality of curves. The 'SumMethod' method 
performs an operation for obtaining a sum of the corre- 
sponding values of a plurality of curves. In the virtual 
curves defined as deserved above, if the configuration 
rate, etc. of the original curve entered in the container 
has been changed by the above described digital feed, 
etc., then the change can be automatically reflected on 
the virtual curve. Using such a virtual curve, a new 
financial transaction that has not been conventionally 
processed can be defined. 

6.7 Procedure of generating option transactions 

[0269] Described below is the procedure of gener- 
ating a transaction Swaptbn which is one of the option 
transactions and is a transaction for an option about 
swaps. 

[0270] First, a swap, that is, an original asset, is 
defined. FIG. 49 shows an example of the generation 
screen. This example shows a swap to be started in the 
future as a 4-year-term swap starting in two years. In the 
swap, payment is made at a fixed rate in response to the 
float rate of the 'LIBOR'. 

[0271] An option about the above described swap 
refers to a transaction in which a contractor determines 
at the starting year, month, and day the situation at that 
point, and has the right to select whether or not the 
swap should be performed. 

[0272] By making a left double dick on the helmet 
icon in the 'Primary tab area at the upper left on the 
screen shown in FIG. 49 after defining the swap as 
described above, the cash flow transaction about the 
swap can be first designed, and the helmet icon is 
changed into the shake-hands icon. 
[0273] Then, by making a left dick on the 'Opt' icon 
of the main control panel, an option definition window is 
displayed as shown in FIG. 50. When the mouse is 
dragged and dropped from the shake-hands icon in the 
'Primary' tab area in the swap definition window to the 
person icon in the 'Primary' tab area in the option defini- 
tion window, the screen display in the option definition 
window changes as shown in FIG. 51. As a result, the 
TOption instance stores in the container an instance of 
the swap object defined as descrfoed above. 
[0274] When a left double dick is made on the hel- 
met icon in the 'Primary tab area in the option definition 
window after setting a parameter corresponding to each 
option in the option definition window, the icon is 
changed into the shake-hands icon as shown in FIG. 
52, and the "TOption instance for the defined option can 
be set In this case, a dass is generated for each model 
of the option, and the setting form of the parameter 
required for the dass can be automatically cfisplayed 
when a model is specified by selecting a parameter dur- 
ing the process. 
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6.8 Procedure of combining financial transactions 

[0275] As described above, the individually gener- 
ated financial transactions can be arbitrarily combined 
to form a virtual transaction. s 
[0276] After each object is set in the swap definition 
window and the option definition window, and the hel- 
met icon in the 'Primary' tab area is changed into the 
shake-hands icon, the 'Opf icon on the main control 
panel is left-clicked. As a result, a book manager 10 
(BOOK MANAGER) window is displayed as shown in 
FIG. 53. 

[0277] When an operation of dragging and dropping 
the mouse from the shake-hands icon in the 'Primary 
tab area in the swap or option definition window to the is 
flask icon in the book manager window is performed on 
a plurality of set objects, the objects can be collectively 
processed as one virtual transaction. 
[0278] Furthermore, a virtual transaction which is a 
compound transaction collectively processed as one 20 
financial transaction in the flask icon can be managed 
using database as an arbitrarily named tree structure in 
the book manager window. To attain this, the mouse is 
dragged and dropped from the flask icon to any tree ele- 
ment in the tree structure in the book manager window. 25 
In this case, using a transaction entry (DEAL ENTRY) 
window displayed as shewn in FIG. 54, attributes such 
as a contractor, a transaction type name, etc. can be set 
for a financial transaction which is a compound transac- 
tion. 30 
[0279] As a result as shown in FIG. 55, a virtual 
transaction which is a compound transaction displayed 
as an ID (15) in the tree structure is stored. It forms the 
Tvirtual Contract shown in, for example, FIG. 2. 
[0280] When a left double click is made on the 35 
financial transaction in the free structure, two magic 
sheets are displayed as shown in FIG. 56. As a result, it 
is apparent that the financial transaction is a compound 
transaction comprising two transaction entities. 

40 

7. Supplementary Descriptions about a storage medium 
storing a program for realizing the aspects of the 
present embodiments 

[0281 ] The present invention can also be designed 45 
as a computer readable storage medium used to direct 
a computer to perform the functions realized by each 
configuration of the above described embodiments of 
the present invention. 

[0282] In this case, a program for realizing various so 
functions according to the embodiments of the present 
invention is executed after being loaded onto the mem- 
ory of the computer using portable storage media such 
as a floppy disk, a CD-ROM disk, an optical disk, etc. 
and through a network circuit. 55 
[0283] With the configuration shown in FIG. 5, the 
class module 501 for operating each class instance in 
the memory, the RDB module 503 for set a relational 



database in an auxiliary storage device, the RDBMS 
module 502 for managing the transmission of data 
between the class module 501 and the RDB module 
503, etc. are implemented as the hardware functions of 
the computer. The RDBMS module 502 implements a 
TQuery method for controlling the issue of an SQL, a 
TStored-Proc method for controlling the stored proce- 
dure, etc. 

Claims 

1 . A general financial risk management apparatus for 
managing risks in compound transactions having 
one or more transaction entities relating to finance, 
comprising: 

one or more transaction entity modeling means 
comprising: 

storage means for individually storing infor- 
mation about the transaction entities, and 
a current price evaluating operation means 
for the transaction entities; and 

virtual transaction means comprising: 

reference information storage means for 
storing a reference information group for 
reference to each of said transaction entity 
modeling means, and 
compound transaction characteristic com- 
putation means for sequentially referring to 
each of said transaction entity modeling 
means in said reference information group, 
obtaining operation results by performing 
sab current price evaluation operation 
means, and computing a characteristic of 
the compound transactions based on each 
of the operation results. 

2. The apparatus according to claim 1 , wherein 

said compound transaction characteristic com- 
putation means comprises factor multiplication 
means for multiplying each of said operation 
results by a predetermined conversion factor. 

3. The apparatus according to claim 1 , wherein 

said transaction entity modeling means is 
implemented as a list structure 

4. The apparatus according to claim 1 , wherein: 

said transaction entity modeling means is a 
module for storing as a class member a param- 
eter for use by said storage means modeling 
the transaction entities, storing the current 
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price evaluation operation means as a method, 
and operating an instance of a predetermined 
class in an object-oriented concept; and 
said virtual transaction means is a module for 
holding said reference information group as a s 
list member in said reference information stor- 
age means, holding said compound transac- 
tion characteristic computation means as a 
virtual method, and operating an instance of a 
predetermined container class in the object-ori- w 
ented concept 

5. The apparatus or a financial transactions modeling 
apparatus according to claim 1 . further comprising: 

15 

financial characteristic computation means for 
computing financial characteristics in each cur- 
rent price evaluating operation performed by 
said current price evaluation operation means, 
and providing each current price evaluation 20 
operation means with the financial characteris- 
tics. 

6. The apparatus according to claim 5. wherein: 

25 

said financial characteristic computation 
means is a module for modeling the financial 
characteristics, and operating an instance of a 
predetermined class in an object-oriented con- 
cept; and 30 
said current price evaluation operation means 
contains reference information, contained in 
the instance of the predetermined class, for ref- 
erence to a predetermined method for comput- 
ing the financial characteristics. 35 

7. The apparatus according to claim 5. wherein: 

said financial characteristic computation 
means comprises: 40 

a plurality of single financial characteristic 
computation means for computing a plural- 
ity of single financial characteristics in 
each current price evaluating operation 45 
performed by said current price evaluation 
operation means; 

virtual financial characteristic computation 
means for computing a new virtual finan- 
cial characteristic by combining said plural- so 
ity of single financial characteristics, and 
providing said virtual financial characteris- 
tic for said current price evaluation opera- 
tion means. 

55 

8. The apparatus according to claim 5. wherein 

said single financial characteristic computation 
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means is a module for modeling each unit 
financial characteristic, and operating each 
instance of a plurality of predetermined classes 
in the object-oriented concept; 
said virtual financial characteristic computation 
means is a module for operating an instance of 
a predetermined super class inherited by the 
plurality of predetermined classes; and 
said current price evaluation operation means 
contains reference information, stored by the 
instance of the predetermined super class for 
reference to a predetermined method for com- 
puting the virtual financial characteristics. 

9. The apparatus according to claim 5. wherein 

said financial characteristics are real time fea- 
tures to be input through a network. 

10. The apparatus according to claim 5, further com- 
prising: 

financial characteristic definition means for 
defining the financial characteristics. 

11. A financial transactions modeling apparatus for 
modeling a transaction sequence settled by settling 
financial transactions in a predetermined transac- 
tion period, comprising: 

one or wore unit transaction modeling means 
comprising: 

unit transaction information storage 
means, provided at each of a receipt side 
and a payment side of the financial trans- 
actions for one or more unit transaction 
period obtained by dividing the predeter- 
mined transaction period for each receipt 
or payment for individually storing infor- 
mation about a unit transaction, and 
current price evaluation operation means 
in the unit transaction period; and 

transaction sequence modeling means com- 
prising] 

reference information storage means for 
holding a reference information group for 
reference to said unit transaction modeling 
means corresponding to each of a receipt 
side and a payment side of the financial 
transactions, and 

transaction sequence characteristic com- 
putation means for sequentially referring to 
said unit transaction modeling means from 
the reference information group in each of 
the receipt side and the payment side of 
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the financial transactions at a predeter- 
mined instruction, performing the current 
price evaluation operation means and 
obtaining operation results, and computing 
a characteristic of the transaction s 
sequence based on each of the operation 
results. 

12. The apparatus according to claim 11 , wherein 

w 

said predetermined period is only a predeter- 
mined point 

1 3. The apparatus according to claim 1 1 , wherein 

15 

said financial transactions are financial goods 
other than a currency; 

14. The apparatus according to claim 1 1 , wherein 

20 

said unit transaction modeling means is imple- 
mented as a list structure. 

15. The apparatus according to claim 11, wherein: 

25 

said unit transaction modeling means is a mod- 
ule for holding as a class member a parameter 
for use in a current price evaluating operation 
performed by said unit transaction information 
storage means in the unit transaction period, 30 
holding the current price evaluation operation 
means as a method, and operating an instance 
of a predetermined class in an object-oriented 
concept; and 

said transaction sequence modeling means is 35 
a module for holding as a list member a refer- 
ence information group in each of a receipt side 
and a payment side of the financial transac- 
tions, holding the transaction sequence char- 
acteristic computation means as a virtual 40 
method, and operating an instance of a prede- 
termined container class in the object-oriented 
concept. 

1 6. The apparatus according to claim 1 1 , wherein 45 



a current price evaluation operation means of 
said unit transaction modeling means com- 
prises discount rate multiplication means 
obtains as a current price evaluating operation 
result a current value by multiplying a current 
price evaluating operation performed by the 
current price evaluation operation means by a 
predetermined discount rate. 

18. The apparatus according to claim 11, further com- 
prising: 

user interface means for computing one or 
more unit transaction periods by dividing the 
predetermined transaction period for each 
receipt or payment based on a setting of date 
information, generating the unit transaction 
modeling means for each computed unit trans- 
action period on each of a receipt side and a 
payment side of the financial transactions, and 
generating a reference information group in 
said transaction sequence modeling means 
corresponding to each of the receipt side and 
the payment side. 

19. The apparatus according to claim 11, further com- 
prising: 

user interface means for changing a parameter 
for financial transactions to be modeled for 
each unit transaction modeling means, and 
issuing a predetermined instruction in 
response to the change. 

20. The apparatus or a financial transactions modeling 
apparatus according to claim 11, further compris- 
ing: 

financial characteristic computation means for 
computing financial characteristics in each cur- 
rent price evaluating operation performed by 
said current price evaluation operation means, 
and providing each current price evaluation 
operation means with the financial characteris- 
tics. 

21. The apparatus according to claim 20, wherein: 

said financial characteristic computation 
means is a module for modeling the financial 
characteristics, and operating an instance of a 
predetermined class in an object-oriented con- 
cept; and 

said current price evaluation operation means 
contains reference information, contained in 
the instance of the predetermined class, for ref- 
erence to a predetermined method for comput- 
ing the financial characteristics. 



a current price evaluation operation means of 
said unit transaction modeling means performs 
a current price evaluating operation based on a 
future value index computed based on any of so 
three types of indices of an interest, an earning 
rate, and a price in the unit transaction period 
corresponding to said unit transaction mode- 
ling means, and an evaluation value independ- 
ent of any indices of the interest, the earning ss 
rage, and the price. 

17. The apparatus according to claim 16, wherein 
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22. Hie apparatus according to claim 20, wherein: 

said financial characteristic computation 
means comprises: 

5 

a plurality of single financial characteristic 
computation means for computing a plural- 
ity of single financial characteristics in 
each current price evaluating operation 
performed by said current price evaluation w 
operation means; 

virtual financial characteristic computation 
means for computing a new virtual finan- 
cial characteristic by combining said plural- 
ity of single financial characteristics, and is 
provicfing said virtual financial characteris- 
tic for said current price evaluation opera- 
tion means. 

23. The apparatus according to claim 20, wherein 20 

said single financial characteristic computation 
means is a module for modeling each unit 
financial characteristic, and operating each 
instance of a plurality of predetermined classes 25 
in the object-oriented concept; 
said virtual financial characteristic computation 
means is a module for operating an instance of 
a predetermined super class inherited by the 
plurality of predetermined classes; and 30 
said current price evaluation operation means 
contains reference information, stored by the 
instance of the predetermined super class for 
reference to a predetermined method for com- 
puting the virtual financial characteristics. 35 

24. The apparatus according to claim 20, wherein 

said financial characteristics are real time fea- 
tures to be input through a network. 40 

25. The apparatus according to claim 20, further com- 
prising: 

financial characteristic definition means for 45 
defining the financial characteristics. 

26. A financial transactions modeling apparatus for 
modeling an option transaction relating to finance, 
comprising: so 

one or more original asset modeling means 
comprising: 

storage means for storing information ss 
about an original asset of the option trans- 
action, and 

a current price evaluation operation 



means; and 
option modeling means comprising: 

reference information storage means for 
holding a reference information group for 
reference to each of said original asset 
modeling means, and 
option transaction characteristic computa- 
tion means for computing a characteristic 
of the option transaction based on each 
operation result from said current price 
evaluation operation means in each of said 
original asset modeling means sequen- 
tially referred to by the reference informa- 
tion group and/or a predetermined 
evaluation model. 

27. The apparatus according to claim 26, wherein 

said original asset modeling means is imple- 
mented as a list structure. 

28. The apparatus according to claim 26, wherein: 

said original asset modeling means is a mod- 
ule for holding as a class member a parameter 
for use in modeling the original asset in said 
storage means, holding said current price eval- 
uation operation means as a method, and 
operating an instance of a predetermined class 
in an object-oriented concept; and 
said option modeling means is a module for 
holding the reference information group as a 
list member, holding said option transaction 
characteristic computation means as a virtual 
method, and operating an instance of a prede- 
termined container class in the object-oriented 
concept. 

29. The apparatus according to claim 26, wherein 

when a date set for the option transaction is in 
an in-the-money state of the option transaction 
at an issue of a predetermined instruction, said 
option modeling means sequentially refers to 
said original asset modeling means in the refer- 
ence information group, obtains operation 
results through said current price evaluation 
operation means, and computes a characteris- 
tic of the option transaction based on each of 
the operation results and the predetermined 
evaluation model; and 

when the date is in an out-of-the-money state 
of the option transaction, said option modeling 
means computes a characteristic of the option 
transaction based only on the predetermined 
evaluation model. 
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30. Hie apparatus or a financial transactions modeling 
apparatus according to claim 26. further compris- 
ing: 

financial characteristic computation means for 
computing financial characteristics in each cur- 
rent price evaluating operation performed by 
said current price evaluation operation means, 
and providing each current price a/aluation 
operation means with the financial characteris- 
tics. 

31 . The apparatus according to claim 30, wherein: 

said financial characteristic computation 
means is a module for modeling the financial 
characteristics, and operating an instance of a 
predetermined class in an object-oriented con- 
cept; and 

said current price evaluation operation means 
contains reference information, contained in 
the instance of the predetermined class, for ref- 
erence to a predetermined method for comput- 
ing the financial characteristics. 

32. The apparatus according to claim 30, wherein: 

said financial characteristic computation 
means comprises: 

a plurality of single financial characteristic 
computation means for computing a plural- 
ity of single financial characteristics in 
each current price evaluating operation 
performed by said current price evaluation 
operation means; 

virtual financial characteristic computation 
means for computing a new virtual finan- 
cial characteristic by combining said plural- 
ity of single financial characteristics, and 
providing said virtual financial characteris- 
tic for said current price evaluation opera- 
tion means. 

33. The apparatus according to claim 30, wherein 

said single financial characteristic computation 
means is a module for modeling each unit 
financial characteristic, and operating each 
instance of a plurality of predetermined classes 
in the object-oriented concept; 
said virtual financial characteristic computation 
means is a module for operating an instance of 
a predetermined super class inherited by the 
plurality of predetermined classes; and 
said current price evaluation operation means 
contains reference information, stored by the 
instance of the predetermined super class for 



reference to a predetermined method for com- 
puting the virtual financial characteristics. 

34. The apparatus according to claim 30, wherein 

5 

said financial characteristics are real time fea- 
tures to be input through a network. 

35. The apparatus according to claim 30, further corn- 
to prising: 

financial characteristic definition means for 
defining the financial characteristics. 

is 36. A computer-reliable storage medium for storing a 
program used and read by a computer for perform- 
ing: 

one or more transaction entity modeling func- 
20 tion for individually modeling respective trans- 

action entities, and performing respective 
current price evaluating operations; and 
virtual transaction realizing function for holding 
a reference information group for reference to 
25 each of said transaction entity modeling func- 

tions, sequentially referring to each of said 
transaction entity modeling functions in the ref- 
erence information group, obtaining operation 
results from the current price evaluating opera- 
30 tion, and computing a characteristic of com- 

pound transactions containing transaction 
entities corresponding to each of said transac- 
tion entity modeling functions based on each of 
the operation results. 

35 

37. A computer-readable storage medium for storing a 
program used and read by a computer for perform- 
ing: 

40 one or more unit transaction modeling function, 

implemented for one or more unit transaction 
period obtained by dividing a predetermined 
transaction period for each receipt or payment 
on each of a receipt side and a payment side of 
45 financial transactions settled by settling the 

financial transactions in the predetermined 
transaction period, for performing a current 
price evaluating operation in the unit transac- 
tion period; and 
so transaction sequence modeling function for 

holding a reference information group for refer- 
ence to said unit transaction modeling function 
corresponding to each of a receipt side and a 
payment side of the financial transactions, 
55 sequentially referring to said unit transaction 

modeling function in the reference information 
group in each of the receipt side and the pay- 
ment side of the financial transactions at a pre- 
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determined instruction, performing the current 
price evaluation operation, obtaining operation 
results, and computing a characteristic of the 
financial transactions based on each of the 
operation results. 

38. A computer-readable storage medium for storing a 
program used and read by a computer for perform- 
ing: 



w 



one or more original asset modeling function 
for individually modeling an original asset of an 
option transaction, and having a current price 
evaluation operation function; and 
an option modeling function for holding a refer- is 
ence information group for reference to each of 
said original asset modeling function, and com- 
puting a characteristic of the option transaction 
based on each operation result from said cur- 
rent price evaluation operation function in each 20 
of said original asset modeling function 
sequentially referred to by the reference infor- 
mation group and/or a predetermined evalua- 
tion model. 
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